This reverts commit r249816.
It broke building llvm with lld:
$ ./bin/FileCheck
./bin/FileCheck: error while loading shared libraries: unexpected PLT reloc type 0x06
I think the only thing that is wrong with this patch is that it is too soon.
The plt we create (and its relocs) don't support lazy loading, so they have
to be relocated as ordinary dynamic relocations.
llvm-svn: 249835
.rela.plt contains list of elements in the PLT, which are liable to the relocation during the dynamic linking.
Differential Revision: http://reviews.llvm.org/D13569
llvm-svn: 249816
The required page alignment is different on different targets. On PowerPC, for
example, we need 64K pages (the loader won't set different permissions on a
finer granularity than that). I've set the existing targets to what I believe
to be the correct values, and have updated the regression tests accordingly.
llvm-svn: 249760
Reapply r249726 (and r249723), hopefully with the correct test fixups this time.
Original commit message:
Address a FIXME in ELF/Writer.cpp: Make VAStart a target-dependent property.
I've set the values for the existing targets to what I believe to be the
correct values, and updated the regression tests accordingly.
llvm-svn: 249752
Address a FIXME in ELF/Writer.cpp: Make VAStart a target-dependent property.
I've set the values for the existing targets to what I believe to be the
correct values, and updated the regression tests accordingly.
llvm-svn: 249723
Previously, output sections that are handled specially by the linker
(e.g. PLT or GOT) were created by Writer and passed to other classes
that need them. The problem was that because these special sections
are required by so many classes, the plumbing work became too much
burden.
This patch is to simply make them accessible from anywhere in the
linker to eliminate the plumbing work once and for all.
http://reviews.llvm.org/D13486
llvm-svn: 249590
The entries are added if there are "_init" or "_fini" entries in
the symbol table respectively. According to the behavior of ld,
entries are inserted even for undefined symbols.
Symbol names can be overridden by using -init and -fini command
line switches. If used, these switches neither add new symbol table
entries nor require those symbols to be resolved.
Differential Revision: http://reviews.llvm.org/D13385
llvm-svn: 249297
Add symbol specified with -u as undefined which may cause additional
object files from archives to be linked into the resulting binary.
Differential Revision: http://reviews.llvm.org/D13345
llvm-svn: 249295
Sort by:
ALLOC
ALLOC && NOBITS
ALLOC & EXEC
ALLOC & EXEC && NOBITS
ALLOC & WRITE
ALLOC & WRITE && NOBITS
<nothing> (ignoring NOBITS)
The dynamic section is finalized early because it adds strings to the dynamic string table, which comes before the dynamic table.
llvm-svn: 249071
The new name starts with a verb, and it does not imply that it errors
out and exit (it acutally can just emit a warning depending on settings.)
llvm-svn: 249016
Sort by:
ALLOC
ALLOC && NOBITS
ALLOC & EXEC
ALLOC & EXEC && NOBITS
ALLOC & WRITE
ALLOC & WRITE && NOBITS
<nothing> (ignoring NOBITS)
The dynamic section is finalized early because it adds strings to the dynamic string table, which comes before the dynamic table.
llvm-svn: 248845
Since FreeBSD 4.1, the kernel expects binaries to be marked with
ELFOSABI_FREEBSD in the ELF header to exec() them. LLD unconditionally
sets OSABI to ELF_OSABINONE, and everything linked with it won't run
on FreeBSD (unless explicitly rebranded).
Example:
% ./aarch64-hello
ELF binary type "0" not known.
zsh: exec format error: ./aarch64-hello
FreeBSD could be modified to accept ELF_OSABINONE, but that would break all
existing binaries, so the kernel needs to support both ABINONE and ABIFREEBSD.
I plan to push this change in FreeBSD one day, which, unfortunately, is
not today. This code patches lld so it sets the header field correctly.
For completeness, the rationale of this change is explained in the FreeBSD
commit message, and it's apparently to pleasee binutils maintainers at the time.
https://svnweb.freebsd.org/base?view=revision&revision=59342
Differential Revision: http://reviews.llvm.org/D13140
llvm-svn: 248554
