[ELF] - Added support for jmp/call relaxations when R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are used.

D15779 introduced basic approach to support new relaxations.
This patch implements relaxations for jmp and call instructions,
described in System V Application Binary Interface AMD64 Architecture Processor 
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, 
B.2 "B.2 Optimize GOTPCRELX Relocations")

Differential revision: http://reviews.llvm.org/D20622

llvm-svn: 270721

This patch makes SectionPiece class 8 bytes smaller on platforms
on which pointer size is 8 bytes. Sean suggested in a post commit
review for r270340 that this could make a differentce, and it
actually is. Time to link clang (with debug info) improved from
6.725 seconds to 6.589 seconds or by about 2%.

Differential Revision: http://reviews.llvm.org/D20613

llvm-svn: 270717

That flag is probably too dangerous to ignore silently.

llvm-svn: 270711

"A zero length string indicates that no augmentation data is present."

The FreeBSD/mips toolchain (GCC 4.2.1) generates .debug_frame sections
containing CIE records that have an empty augmentation string.

Differential Revision: http://reviews.llvm.org/D19928

llvm-svn: 270706

System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 
(https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations")
introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.

That patch implements the next relaxation: 
mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg
and also opens door for implementing all other ones.

Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself.

Differential revision: http://reviews.llvm.org/D15779

llvm-svn: 270705

Thanks to Sean for pointing it out.

llvm-svn: 270660

llvm-svn: 270659

llvm-svn: 270657

llvm-svn: 270652

llvm-svn: 270651

scanReloc and the functions on which scanReloc depends is in total
more than 600 lines of code. Since scanReloc does not depend on Writer,
it is better to move it into a separate file.

Differential Revision: http://reviews.llvm.org/D20554

llvm-svn: 270606

Thanks to Rui for the suggestion.

llvm-svn: 270601

llvm-svn: 270573

This patch addresses a post-commit review for r270325. r270325
introduced getReloc function that searches a relocation for a
given range. It always started searching from beginning of relocation
vector, so it was slower than before. Previously, we used to use
the fact that the relocations are sorted. This patch restore it.

llvm-svn: 270572

llvm-svn: 270568

llvm-svn: 270563

llvm-svn: 270555

This reverts commit r270551.

Sorry, I commited the wrong branch :-(

llvm-svn: 270554

llvm-svn: 270551

I think this function was too short to be an independent function.

llvm-svn: 270534

Since the symbol table is a singleton class and globally accessible,
we don't need to pass it around.

llvm-svn: 270533

llvm-svn: 270532

llvm-svn: 270531

scanReloc does not depend on Writer, so it doesn't have to be
in the class.

llvm-svn: 270530

Previously, we created a .bss section when needed. We had a function
ensureBss() for that purpose. Turned out that was error-prone
because it was easy to forget to call that function before accessing
the .bss section.

This patch always make the BSS section. The section is added to the
output when it's not empty.

llvm-svn: 270527

llvm-svn: 270526

Copy relocations are relocations to copy data from DSOs to
executable's .bss segment at runtime. It doesn't make sense to
create such relocations for zero-sized symbols.

GNU linkers don't agree with each other. ld rejects such
relocation/symbol pair. gold don't reject that but do not create
copy relocations as well.  I took the former approach because
I don't think the latter is what user wants.

llvm-svn: 270525

llvm-svn: 270523

This function does not depend on EhOutputSection class.

llvm-svn: 270522

The dead declarations made MSVC to warn on explicit template
instantiations of the classes.

llvm-svn: 270471

Previously, mergeable section's constructors did more than just
setting member variables; it split section contents into small
pieces. It is not always computationally cheap task because if
the section is a mergeable string section, it needs to scan the
entire section to split them by NUL characters.

If a section would be thrown away by GC, that cost ended up
being a waste of time. It is going to be larger problem if the
section is compressed -- the whole time to uncompress it and
split it up is going to be a waste.

Luckily, we can defer section splitting after GC. We just have
to remember which offsets are in use during GC and apply that later.
This patch implements it.

Differential Revision: http://reviews.llvm.org/D20516

llvm-svn: 270455

llvm-svn: 270451

llvm-svn: 270448

Since now we always set SHT_PROGBITS to .eh_frame sections,
this code path is not executed at runtime.

llvm-svn: 270446

.eh_frame_hdr assumes that there is only one .eh_frame and
ensures it by assertions. This patch makes .eh_frame a real
singleton object to simplify.

llvm-svn: 270445

.eh_frame is always ".eh_frame" and its attribute is fixed.
No need to copy from inputs to outputs. GNU gold also sets
SHT_PROGBITS.

llvm-svn: 270443

llvm-svn: 270442

Previously, EhFrameHdr section computed addresses to which FDEs are
applied to. This is not an ideal design because EhFrameHdr does not
know much about FDEs unless EhFrame passes the information to EhFrameHdr.
It is what we did.

This patch simplifies the code by making EhFrame to compute the
values and pass the cooked information to EhFrameHdr. EhFrameHdr no
longer have to know about the details of FDEs such as FDE encodings.

llvm-svn: 270393

llvm-svn: 270390

llvm-svn: 270388