This matches ld.bfd and ld.gold behavior. The change is simple enough
and avoid trouble to consumers (they don't have to change their Makefiles).
Side note: found while trying to build FreeBSD base system with lld.
llvm-svn: 251408
.eh_frame sections need to be preserved if they refer to live sections.
So the liveness relation is reverse for eh_frame sections. For now,
we simply preserve all .eh_frame sections. Thanks Rafael for pointing
this out. .jcr are kept for the same reason.
llvm-svn: 251068
Section garbage collection is a feature to remove unused sections
from outputs. Unused sections are sections that cannot be reachable
from known GC-root symbols or sections. Naturally the feature is
implemented as a mark-sweep garbage collector.
In this patch, I added Live bit to InputSectionBase. If and only
if Live bit is on, the section will be written to the output.
Starting from GC-root symbols or sections, a new function, markLive(),
visits all reachable sections and sets their Live bits. Writer then
ignores sections whose Live bit is off, so that such sections are
excluded from the output.
This change has small negative impact on performance if you use
the feature because making sections means more work. The time to
link Clang changes from 0.356s to 0.386s, or +8%.
It reduces Clang size from 57,764,984 bytes to 55,296,600 bytes.
That is 4.3% reduction.
http://reviews.llvm.org/D13950
llvm-svn: 251043
This patch implements --hash-style command line switch.
* By default, or with "sysv" or "both" parameters, the linker generates
a standard ELF hash section.
* With "gnu" or "both", it produces a GNU-style hash section.
That section requires the symbols in the dynamic symbol table section, which
are referenced in the GNU hash section, to be placed after not hashed ones and
to be sorted to correspond the order of hash buckets in the GNU Hash section.
The division function, as well as estimations for the section's parameters,
are just the first rough attempt and the subjects for further adjustments.
Differential Revision: http://reviews.llvm.org/D13815
llvm-svn: 251000
The section header table index of the entry that is associated with the section name string table.
Differential Revision: http://reviews.llvm.org/D13904
llvm-svn: 250836
Target has supportsLazyRelocations() method which can switch lazy relocations on/off (currently all targets are OFF except x64 which is ON). So no any other targets are affected now.
Differential Revision: http://reviews.llvm.org/D13856?id=37726
llvm-svn: 250808
The option now just sets NOW bit in DT_FLAGS_1 but some loaders
seem to require also BIND_NOW bit to be set in DT_FLAGS. This is,
also, what ld.bfd and gold do.
Differential Revision: http://reviews.llvm.org/D13883
llvm-svn: 250799
The two names are similar enough that they might lead to confusion.
The output of readobj clarifies but I missed it when I originally
committed this. Found while linking FreeBSD userland with lld.
llvm-svn: 250739
The reason of collecting all undefines in vector is that during reading files we already need to have Symtab created. Or like was done in that patch - to put undefines from scripts somewhere to delay Symtab.addUndefinedOpt() call.
Differential Revision: http://reviews.llvm.org/D13870
llvm-svn: 250711
Instead of specifically creating .plt entries for weak undef symbols, mirror
the logic in r250584, and use canBePreempted to determine is a REL24 relocation
needs a .plt entry. This might cause relocateOne to be called for a weak undef
symbol, with a REL24 relocation, but ignore this as a special case (this will
cause SA == 0, which won't happen under any other circumstance).
llvm-svn: 250597
There is sometimes no need to generate relocation via PLT.
Example - when symbol is not undefined and we are not creating shared library. Then we can create relative relocation instead of referencing and creating PLT records.
Differential Revision: http://reviews.llvm.org/D13835
llvm-svn: 250584
When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to
0, and we're creating a shared library, we need to make sure that it stays 0
(because code that conditionally calls the weak function tests for this).
Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation
targets, making the address of the undefined weak symbol equal to the base
address of the shared library (which is non-zero). In general, we should not be
creating RelativeReloc relocs for undef weak symbols.
llvm-svn: 250558
R_PPC64_TOC does not have an associated symbol, but does have a non-zero VA
that target-specific code must compute using some non-trivial rule. We
handled this as a special case in PPC64TargetInfo::relocateOne, where
we knew to write this special address, but that did not work when creating shared
libraries. The special TOC address needs to be the subject of a
R_PPC64_RELATIVE relocation, and so we also need to know how to encode this
special address in the addend of that relocation.
Thus, some target-specific logic is necessary when creating R_PPC64_RELATIVE as
well. To solve this problem, we teach getLocalRelTarget to handle R_PPC64_TOC
as a special case. This allows us to remove the special case in
PPC64TargetInfo::relocateOne (simplifying code there), and naturally allows the
existing logic to do the right thing when creating associated R_PPC64_RELATIVE
relocations for shared libraries.
llvm-svn: 250555
If a section name is valid as a C identifier (which is rare because of
the leading '.'), linkers are expected to define __start_<secname> and
__stop_<secname> symbols. They are at beginning and end of the section,
respectively. This is not requested by the ELF standard, but GNU ld and
gold provide this feature.
llvm-svn: 250432
Unfortunately, the check was not as dead as I had thought, and adjusting the
starting VA again exposed the problem. We end up trying to relocate the bl
(using a 24-bit relative offset) to a symbol address of zero, and in general,
that does not fit.
Thus, reverting for now, and adding a test case.
llvm-svn: 250423
After some additional post-commit (post-revert) discussion and research, this
reverts, in part, r250205, so the ABI-recommended starting address can be used
on PPC64 (as is done by other linkers).
Also, this addresses the FIXME in ELF/Writer.cpp by making VAStart a
target-dependent property.
llvm-svn: 250378
If an argument for --entry is a number, that's not a symbol name but
an absolute address. If that's the case, the address is directly set
to ELF header's e_entry.
llvm-svn: 250334
Previously, we used input section names as output section names.
That resulted that we created lots of sections for comdat
or -f{function,data}-section sections.
This patch reduces the number of sections by dropping suffix from
all section names which start with ".text.", ".rodata.", ".data."
or ".bss.". GNU linker does this using the internal linker script,
but for LLD I chose to do that directly.
Interestingly, this makes the linker faster. Time to link Clang
is this.
Before:
real 0m0.537s
user 0m0.433s
sys 0m0.104s
After:
real 0m0.390s
user 0m0.268s
sys 0m0.120s
It make sense because previously we created 57659 sections now only 27.
llvm-svn: 250315
- Make the `MipsTargetInfo` template class with `ELFType` argument. Use
the argument to select an appropriate relocation type and read/write
routines.
- Add template function `add32` to add-and-write relocation value in
both big and little endian cases. Keep the `add32le` to reduce code
changes.
Differential Revision: http://reviews.llvm.org/D13723
llvm-svn: 250297
The documentation says: "You may separate commands using semicolons",
so they seem to be optional.
Differential Revision: http://reviews.llvm.org/D13703
llvm-svn: 250223
This has turned out to be unnecessary, and while some ability to set VAStart
will be needed at some point, this is not clearly the right direction.
llvm-svn: 250205
BSD's DSO files have undefined symbol "__progname" which is defined
in crt1.o. On that system, both user programs and system shared
libraries depend on each other.
In general, we need to put symbols defined by user programs which are
referenced by shared libraries to user program's .dynsym.
http://reviews.llvm.org/D13637
llvm-svn: 250176
What was done:
1) .got.plt section is created for functions that requires PLT. .got.plt has 3 predefined empty entries now that are required for dynamic linker.
Also other new items created are configured to have correct jump to PLT[N].
2) PLT section now has PLT[0] entry, also others ones are configured to support PLT->GOT(.got.plt) calls.
3) Implemented .rel[a].plt sections (based on patch http://reviews.llvm.org/D13569).
4) Fixed plt relocations types (based on patch http://reviews.llvm.org/D13589).
NOTES:
The .plt.got zero entry is still empty now. According to ELF specification it should hold the address of the dynamic structure, referenced with the symbol
_DYNAMIC. The _DYNAMIC entry points to the .dynamic section which contains information used by the ELF interpreter to setup the binary.
Differential Revision: http://reviews.llvm.org/D13651
llvm-svn: 250169
Under PPC64 ELF v1 ABI, the symbols associated with each function name don't
point directly to the code in the .text section (or similar), but rather to a
function descriptor structure in a special data section named .opd. The
elements in the .opd structure include a pointer to the actual code, and a the
relevant TOC base value. Both of these are themselves set by relocations.
When we have a local call, we need the relevant relocation to refer directly to
the target code, not to the function-descriptor in the .opd section. Only when
we have a .plt stub do we care about the address of the .opd function
descriptor itself.
So we make a few changes here:
1. Always write .opd first, so that its relocated data values are available
for later use when writing the text sections. Record a pointer to the .opd
structure, and its corresponding buffer.
2. When processing a relative branch relocation under ppc64, if the
destination points into the .opd section, read the code pointer out of the
function descriptor structure and use that instead.
This this, I can link, and run, a dynamically-compiled "hello world"
application on big-Endian PPC64/Linux (ELF v1 ABI) using lld.
llvm-svn: 250122
Under the PPC64 ELF ABI, functions that might call into other modules (and,
thus, need to load a different TOC base value into %r2), need to restore the
old value after the call. The old value is saved by the .plt code, and the
caller only needs to include a nop instruction after the call, which the linker
will transform into a TOC restore if necessary.
In order to do this the relocation handler needs two things:
1. It needs to know whether the call instruction it is modifying is targeting
a .plt stub that will load a new TOC base value (necessitating a restore after
the call).
2. It needs to know where the buffer ends, so that it does not accidentally
run off the end of the buffer when looking for the 'nop' instruction after the
call.
Given these two pieces of information, we can insert the restore instruction in
place of the following nop when necessary.
llvm-svn: 250110
This is mostly an adaptation of the code in LLVM's
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, and handles a sufficient
number of relocations to link a 'hello world' program on big-Endian PPC64/Linux
(ELF v1 ABI).
llvm-svn: 250101
PPC64 has several special sections that are intended to be accessed from the
TOC base pointer. When a .got is present, the TOC base pointer is .got + 0x8000
(as specified by the ABI). Furthermore, the glibc startup code contains an
assumption that a 16-bit relocation can hold the offset from the TOC base value
to the beginning of the .toc section. Thus, we need to make sure that .toc
appears after .got. This much, at least, is required in practice. The other
PPC64 special sections (.toc, .toc1, .opd, etc.) should also be close by to
optimize access by smaller TOC-base-pointer offsets.
llvm-svn: 250100
In order to actually verify the condition, we have to use a weak symbol.
If an undefined symbol is not used at all, it is naturally ignored not by
the code for --as-needed but by the code for something else.
llvm-svn: 250062
This patch adds AsNeeded and IsUsed bool fields to SharedFile. AsNeeded bit
is set if the DSO is enclosed with --as-needed and --no-as-needed. IsUsed
bit is off by default. When we adds a symbol to the symbol table for dynamic
linking, we set its SharedFile's IsUsed bit.
If AsNeeded is set but IsUsed is not set, we don't want to write that
file's SO name to DT_NEEDED field.
http://reviews.llvm.org/D13579
llvm-svn: 249998
In the linker script, -l and = have the same meaning as in the command line.
In addition to that, if a path is not absolute, the path needs to be searched
from the search paths. This patch implements them.
llvm-svn: 249967
Previously, we reserved the first page for the program header, so no
sections would be written to very beginning of the output file.
FreeBSD requires .interp section be exist on the first page, so that
was not good.
This patch calculates the size of the program header and then assign
addresses to the sections. Now the first section is located next to
the program header. Because the first section is .interp, it's very
likely to be on the first page.
llvm-svn: 249957
SymbolTable was not a template class. Instead we had switch-case-based
type dispatch to call desired functions. We had to do that because
SymbolTable was created before we know what ELF type objects had been
passed.
Every time I tried to add a new function to the symbol table, I had to
define a dispatcher which consist of a single switch statement.
It also brought an restriction what the driver can do. For example,
we cannot add undefined symbols before any files are added to the symbol
table. That's because no symbols can be added until the symbol table
knows the ELF type, but when it knows about that, it's too late.
In this patch, the driver makes a decision on what ELF type objects
are being handled. Then the driver creates a SymbolTable object for
an appropriate ELF type.
http://reviews.llvm.org/D13544
llvm-svn: 249902
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
`not` command on Windows is not able to find an executable from PATH
if a given command already has an extension even if the extension is
not ".exe".
llvm-svn: 249630
Michael J. Spencer