The referenced symbol is expected to point to an R_RISCV_*_HI20
relocation. An absolute symbol has no associated section, therefore
there cannot be a matching R_RISCV_*_HI20.
This fixes the crash reported by PR42038. For reference, ld.bfd errors:
(.init+0x4): dangerous relocation: %pcrel_lo missing matching %pcrel_hi
Differential Revision: https://reviews.llvm.org/D63273
llvm-svn: 365049
This reverts r365015.
David Zarzycki reported this change broke stage2 and stage3 tests. The
root cause is still not very clear, but I guess some SHF_MERGE sections
with the same name have different alignments. They were not merged
before but were merged after r365015.
Something that assumes address uniqueness of such mergeable data caused
the bug.
llvm-svn: 365048
gcc may generate .debug_info/.debug_aranges/.debug_line/etc that are
relocated by R_RISCV_ADD*/R_RISCV_SUB* pairs.
Allow R_RISCV_ADD in non-SHF_ALLOC section to fix link errors like:
ld.lld: error: print.c:(.debug_frame+0x60): has non-ABS relocation R_RISCV_ADD64 against symbol '.L0 '
Differential Revision: https://reviews.llvm.org/D63259
llvm-svn: 365035
This should fix PR42289: the Linux kernel has a use case that input
files have .rodata.cst32 sections with different alignments. The
expectation (and what ld.bfd and gold do) is that in the -r link, there
is only one .rodata.cst32 (SHF_MERGE sections with different alignments
can be combined), but lld currently creates one for each different
alignment.
The current merging strategy:
1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize and
sh_addralign). String merging is performed among a group, even if -O0 is specified.
2) Create one output section for each group. This is a special case in
addInputSec().
This patch changes 1) to:
1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize).
String merging is performed among a group, even if -O0 is specified.
We will thus create just one .rodata.cst32 . This also improves merging
efficiency when sections with the same name but different alignments are
combined.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63432
llvm-svn: 365015
This matches the wasm lld and GNU ld behavior.
The ELF linker has special handling for bitcode archives but if that
doesn't kick in we probably want to error out rather than silently
ignore the library.
Differential Revision: https://reviews.llvm.org/D63781
llvm-svn: 364998
Add Triple::riscv64 and Triple::riscv32 to getBitcodeMachineKind for get right
e_machine during LTO.
Reviewed By: ruiu, MaskRay
Differential Revision: https://reviews.llvm.org/D52165
llvm-svn: 364996
Fixes PR42442
t.o has a STB_GLOBAL undef ref to f
t2.so has a STB_WEAK undef ref to f
t1.so defines f
ld.lld t.o t1.so t2.so currently sets the binding of `f` to STB_WEAK.
This is not correct because there exists a STB_GLOBAL undef ref from a
regular object. The problem is that resolveUndefined() doesn't check
if the undef ref is seen for the first time:
if (isShared() || isLazy() || (isUndefined() && Other.Binding != STB_WEAK))
Binding = Other.Binding;
The isShared() condition should be `isShared() && !Referenced`
where Referenced is set to true after an undef ref is seen.
In practice, when linking a pthread program with glibc:
// a.o
#include <pthread.h>
pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER;
int main() { pthread_mutex_unlock(&mu); }
{clang,gcc} -fuse-ld=lld a.o -lpthread # libpthread.so is linked before libgcc_s.so.1
The weak undef pthread_mutex_unlock in libgcc_s.so.1 makes the result
weak, which diverges from GNU linkers where STB_DEFAULT is used:
23: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock
(Note, if -pthread is used instead, libpthread.so will be linked **after**
libgcc_s.so.1 . lld sets the binding to the expected STB_GLOBAL)
Similar linking sequences (ld.lld t.o t1.so t2.so) appear to be used by
Go, which cause a build error https://github.com/golang/go/issues/31912.
Reviewed By: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D63974
llvm-svn: 364913
RISC-V psABI doesn't specify TLS relaxation. It can be handled the same
way as we handle ARM TLS. RISC-V TLS is even simpler because GD/LD use
the same relocation type.
Reviewed By: jrtc27, ruiu
Differential Revision: https://reviews.llvm.org/D63220
llvm-svn: 364813
* Handle initial relocation types: R_RISCV_CALL_PLT and R_RISCV_GOT_HI20.
* Produce dynamic relocation types: R_RISCV_COPY, R_RISCV_RELATIVE, R_RISCV_JUMP_SLOT.
* Define SymbolRel as R_RISCV_{32,64}
* Generate PLT header: it is used by lazy binding PLT in glibc.
* R_RISCV_CALL is changed from R_PC to R_PC_PLT. If the target symbol is preemptable, this will suppress an unnecessary "canonical PLT".
This behavior is different from ld.bfd but it is agreed the current lld behavior is favored.
I have received positive responses from the binutils maintainer that the ABI/binutils implementation can be improved, see:
https://github.com/riscv/riscv-elf-psabi-doc/issues/98https://sourceware.org/bugzilla/show_bug.cgi?id=24685
Many -no-pie/-pie/-shared programs linked against musl or glibc should work with this patch.
Reviewed By: jrtc27
Differential Revision: https://reviews.llvm.org/D63076
llvm-svn: 364812
GNU windres, and MS cvtres (unless the /readonly option is passed)
produce read-write .rsrc sections, when creating resource object files.
This caused the sections to not be added to the precreated RsrcSec,
and therefore not be added to the data directory.
Differential Revision: https://reviews.llvm.org/D63837
llvm-svn: 364660
If .rela.plt is mentioned in a linker script, it might be preserved
even if it is empty. In that case, LLD created DT_JMPREL and DT_PLTGOT
dynamic tags. When the tags exist, a dynamic loader writes values into
reserved slots in .got.plt to support lazy symbol resolution.
The problem is that, in fact, the linker has not reserved that space,
and the writing may occur into the memory allocated for something else.
Differential Revision: https://reviews.llvm.org/D63869
llvm-svn: 364639
Summary:
This is needed for address sanitizer on Emscripten. As everything in
memory starts at the value passed to --global-base, everything before
that can be used as shadow memory.
This symbol is added so that the library for the ASan runtime can know
where the shadow memory ends and real memory begins.
This is split from D63742.
Reviewers: tlively, aheejin, sbc100
Subscribers: sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63833
llvm-svn: 364467
This restores r361830 "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"
and dependent commits (r362218, r362497) which were reverted by r364321, with a fix of a --gdb-index issue.
.rela.debug_ranges contains relocations of range list entries:
// start address of a range list entry
// old: 0; after r361830: 0
00000000000033a0 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + 0
// end address of a range list entry
// old: 0xe; after r361830: 0
00000000000033a8 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + e
If both start and end addresses of a range list entry resolve to 0,
DWARFDebugRangeList::isEndOfListEntry() will return true, then the
.debug_range decoding loop will terminate prematurely:
while (true) {
decode StartAddress
decode EndAddress
if (Entry.isEndOfListEntry()) // prematurely
break;
Entries.push_back(Entry);
}
In lld/ELF/SyntheticSections.cpp, readAddressAreas() will read
incomplete address ranges and the resulting .gdb_index will be
incomplete. For files that gdb hasn't loaded their debug info, gdb uses
.gdb_index to map addresses to CUs. The absent entries make gdb fail to
symbolize some addresses.
To address this issue, we simply allow relocations to undefined symbols
in DWARF.cpp:findAux() and let RelocationResolver resolve them.
This patch should fix:
[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067
llvm-svn: 364391
Summary:
Before:
```
wasm-ld: error: Relocations not in offset order
```
After
```
wasm-ld: error: While processing `libjulia.so`: Relocations not in offset order
```
At least this way you get to find out which input file is malformed.
Reviewers: sbc100
Differential Revision: https://reviews.llvm.org/D63694
llvm-svn: 364368
Summary:
The list of relocations with addend in lld was missing `R_WASM_MEMORY_ADDR_REL_SLEB`,
causing `wasm-ld` to generate corrupted output. This fixes that problem and while
we're at it pulls the list of such relocations into the Wasm.h header, to avoid
duplicating it in multiple places.
Reviewers: sbc100
Differential Revision: https://reviews.llvm.org/D63696
llvm-svn: 364367
This is fairly common with wasm since GNU ar (most likely the system ar)
doesn't support the wasm object format so user who don't override AR
will end up with archives without an index. We don't want to silently
ignore this issue.
In the future we could choose to instead behave like the ELF backend and
read the symbols from each object file in the archive if they are all of
the same type. However, error'ing out seem like a conservative approach
for now.
Fixes: PR42376
Differential Revision: https://reviews.llvm.org/D63739
llvm-svn: 364338
(In effect, reverting "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded".)
It caused debug info problems in LibreOffice [1] and Chromium/V8 [2].
Reverting until those can be fixed.
It also reverts r362497 "STT_SECTION symbol should be defined" on .eh_frame, .debug*, .zdebug* and .gcc_except_table"
which was landed as a follow-up to the above.
> With -r or --emit-relocs, we warn `STT_SECTION symbol should be defined`
> on relocations to discarded section symbol. This was added as an error
> in rLLD319404, but was not so effective before D61583 (it turned the
> error to a warning).
>
> Relocations from .eh_frame .debug* .zdebug* .gcc_except_table to
> discarded .text are very common and somewhat expected. Don't warn/error
> on them. As a reference, ld.bfd has a similar logic in
> _bfd_elf_default_action_discarded() to allow these cases.
>
> Delete invalid-undef-section-symbol.test because what it intended to
> check is now covered by the updated comdat-discarded-reloc.s
>
> Delete relocatable-eh-frame.s because we allow relocations from
> .eh_frame as a special case now.
And finally it reverts r362218 "[ELF] Replace a dead test in getSymVA() with assert()"
as that also depended on the main change reverted here.
> Symbols relative to discarded comdat sections are Undefined instead of
> Defined now (after D59649 and D61583). The `== &InputSection::Discarded`
> test becomes dead. I cannot find a test related to this behavior.
[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067
llvm-svn: 364321
lld/coff already deduplicated undefined symbols on a TU level: It would
group all references to a symbol from a single TU. This makes it so that
references from all TUs to a single symbol are grouped together.
Since lld/coff almost did what I thought it did already, the patch is
much smaller than the elf version. The only not local change is that
getSymbolLocations() now returns a vector<string> instead of a string,
so that the undefined symbol reporting code can know how many references
to a symbol exist in a given TU.
Fixes PR42260 for lld/coff.
Differential Revision: https://reviews.llvm.org/D63646
llvm-svn: 364285
r360841 introduced CommonSymbol class. An unintended behavioral change
introduced by that change was that common symbols are not internalized
by LTO under some condition. This patch fixes that issue.
The issue occurred under the following condition:
1. There exists a common symbol
2. At least one DSO is given to lld or -pie is used
If the above conditions are met, Symbol::includeInDynsym() returned a
wrong value for a common symbol.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41978
Differential Revision: https://reviews.llvm.org/D63752
llvm-svn: 364273
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.
The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.
The upper bound of the error message is not correct. Fix it as well.
The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63690
llvm-svn: 364164
Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.
This patch is an attempt to simplify the logic.
Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.
Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.
For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.
Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.
Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63383
llvm-svn: 363928
Some versions of the Visual C++ 2015 runtime have line tables with the
subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to
be DEBUG_S_IGNORE. This appears to implement the intended behavior.
llvm-svn: 363724
Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.
For now, only YAML is supported.
llvm-svn: 363573
This matches how it is done for .xdata and .pdata already.
On i386, the symbol name in the section name suffix does not contain
the extra underscore prefix.
This is one part of a fix for PR42217.
Differential Revision: https://reviews.llvm.org/D63350
llvm-svn: 363456
In processRelocAux(), our handling of 1) link-time constant and 2) weak
undef is the same, so put them together to simplify the logic.
This moves the weak undef code around. The result is that: in a writable
section (or -z notext), we will no longer emit dynamic relocations for
weak undefined symbols.
The new behavior seems to match GNU linkers, and improves consistency
with the case of a readonly section.
The condition `!Config->Shared` was there probably because it is common
for a -shared link not to specify full dependencies. Keep it now but we
may revisit the decision in the future.
gABI says:
> The behavior of weak symbols in areas not specified by this document is
> implementation defined. Weak symbols are intended primarily for use in
> system software. Applications using weak symbols are unreliable since
> changes in the runtime environment might cause the execution to fail.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63003
llvm-svn: 363399
This patch adds new command line option `--undefined-glob` to lld.
That option is a variant of `--undefined` but accepts wildcard
patterns so that all symbols that match with a given pattern are
handled as if they were given by `-u`.
`-u foo` is to force resolve symbol foo if foo is not a defined symbol
and there's a static archive that contains a definition of symbol foo.
Now, you can specify a wildcard pattern as an argument for `--undefined-glob`.
So, if you want to include all JNI symbols (which start with "Java_"), you
can do that by passing `--undefined-glob "Java_*"` to the linker, for example.
In this patch, I use the same glob pattern matcher as the version script
processor is using, so it does not only support `*` but also `?` and `[...]`.
Differential Revision: https://reviews.llvm.org/D63244
llvm-svn: 363396
If .sdata is absent, linker synthesized __global_pointer$ gets a section index of SHN_ABS.
(ld.bfd has a similar issue: binutils PR24678)
Scrt1.o may use `lla gp, __global_pointer$` to reference the symbol PC
relatively. In -pie/-shared mode, lld complains if a PC relative
relocation references an absolute symbol (SHN_ABS) but ld.bfd doesn't:
ld.lld: error: relocation R_RISCV_PCREL_HI20 cannot refer to lute symbol: __global_pointer$
Let the reference of __global_pointer$ to force creation of .sdata to
fix the problem. This is similar to _GLOBAL_OFFSET_TABLE_, which forces
creation of .got or .got.plt .
Also, change the visibility from STV_HIDDEN to STV_DEFAULT and don't
define the symbol for -shared. This matches ld.bfd, though I don't
understand why it uses STV_DEFAULT.
Reviewed By: ruiu, jrtc27
Differential Revision: https://reviews.llvm.org/D63132
llvm-svn: 363351
PDBs may not necessarily contain an IPI stream. Handle this case
gracefully.
The test case was verified to work with MS link.exe.
Patch by Vladimir Panteleev, with a small simplification
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D63178
llvm-svn: 363213
An unrecognized signature (magic) at the beginning of a debug section
should not be a fatal error; it only means that the debug information
is in a format that is not supported by LLD. This can be due to it
being in CodeView versions 3 or earlier. These can occur in old import
libraries from legacy SDKs.
The test case was verified to work with MS link.exe.
Patch by Vladimir Panteleev!
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D63177
llvm-svn: 363212
R_RISCV_{ADD,SET,SUB}* are used for local label computation.
Add a new RelExpr member R_RISCV_ADD to represent them.
R_RISCV_ADD is treated as a link-time constant because otherwise
R_RISCV_{ADD,SET,SUB}* are not allowed in -pie/-shared mode.
In glibc Scrt1.o, .rela.eh_frame contains such relocations.
Because .eh_frame is not writable, we get this error:
ld.lld: error: can't create dynamic relocation R_RISCV_ADD32 against symbol: .L0 in readonly segment; recompil object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in ..../riscv64-linux-gnu/lib/Scrt1.o
With D63076 and this patch, I can run -pie/-shared programs linked against glibc.
Note llvm-mc cannot currently produce R_RISCV_SET* so they are not tested.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63183
llvm-svn: 363128
Summary:
clang (as of 2019-06-12) / gcc (as of 8.2.1) PPC64 may emit a .rela.toc
which references an embedded switch table in a discarded .rodata/.text
section. The .toc and the .rela.toc are incorrectly not placed in the
comdat.
Technically a relocation from outside the group is not allowed by the ELF spec:
> A symbol table entry with STB_LOCAL binding that is defined relative
> to one of a group's sections, and that is contained in a symbol table
> section that is not part of the group, must be discarded if the group
> members are discarded. References to this symbol table entry from
> outside the group are not allowed.
Don't report errors to work around the bug.
This should fix the ppc64le-lld-multistage-test bot while linking llvm-tblgen:
ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv
>>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o
>>> referenced by CodeGenRegisters.cpp
>>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0)
Some other PPC specific sections may have similar problems. We can blacklist more
section names when problems occur.
// A simple program that reproduces the bug.
// Note .rela.toc (outside the group) references a section symbol (STB_LOCAL) in a group.
void puts(const char *);
struct A {
void foo(int a) {
switch (a) {
case 0: puts("0"); break;
case 1: puts("1"); puts("1"); break;
case 2: puts("2"); break;
case 3: puts("3"); puts("4"); break;
case 4: puts("4"); break;
case 5: puts("5"); puts("5"); break;
case 6: puts("6"); break;
}
}
int a;
};
void foo(A x) { x.foo(x.a); }
Reviewers: ruiu, sfertile, espindola
Reviewed By: ruiu
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63182
llvm-svn: 363126
Summary: Deduplicate S_CONSTANTS when linking, if they have the same value.
Reviewers: rnk
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63151
llvm-svn: 363089
Users are exepcted to pass all .res files to the linker, which then
merges all the resource in all .res files into a tree structure and then
converts the final tree structure to a .obj file with .rsrc$01 and
.rsrc$02 sections and then links that.
If the user instead passes several .obj files containing such resources,
the correct thing to do would be to have custom code to merge the trees
in the resource sections instead of doing normal section merging -- but
link.exe rejects if multiple resource obj files are passed in with
LNK4078, so let lld-link do that too instead of silently writing broken
.rsrc sections in that case.
The only real way to run into this is if users manually convert .res
files to .obj files by running cvtres and then handing the resulting
.obj files to lld-link instead, which in practice likely never happens.
(lld-link is slightly stricter than link.exe now: If link.exe is passed
one .obj file created by cvtres, and a .res file, for some reason it
just emits a warning instead of an error and outputs strange looking
data. lld-link now errors out on mixed input like this.)
One way users could accidentally run into this is the following
scenario: If a .res file is passed to lib.exe, then lib.exe calls
cvtres.exe on the .res file before putting it in the output .lib.
(llvm-lib currently doesn't do this.)
link.exe's /wholearchive seems to only add obj files referenced from the
static library index, but lld-link current really adds all files in the
archive. So if lld-link /wholearchive is used with .lib files produced
by lib.exe and .res files were among the files handed to lib.exe, we
previously silently produced invalid output, but now we error out.
link.exe's /wholearchive semantics on the other hand mean that it
wouldn't load the resource object files from the .lib file at all.
Since this scenario is probably still an unlikely corner case,
the difference in behavior here seems fine -- and lld-link might have to
change to use link.exe's /wholearchive semantics in the future anyways.
Vaguely related to PR42180.
Differential Revision: https://reviews.llvm.org/D63109
llvm-svn: 363078
So that R_RISCV_PCREL_LO12_[IS] are considered as link-time constants in
-pie mode, otherwise there are bogus errors:
ld.lld: error: can't create dynamic relocation R_RISCV_PCREL_LO12_I against symbol: .L0 in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63123
llvm-svn: 363064
The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`.
When the symbol is non-preemptable, this allows absolute relocation
types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are
disallowed by ld.bfd and gold, e.g.
ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC
This patch:
a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a
symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64).
As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve
GOT slots that are link-time constants. Since we now use Target->SymbolRel
to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets.
R_*_GLOB_DAT cannot be used as static relocation types.
b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`.
Some tests are caught by the improved error checking (ld.bfd/gold also
issue errors on them). Many misuse .long where .quad should be used
instead.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63121
llvm-svn: 363059
The previous name "%lib" doesn't trigger any actual replacement. It
creates the file "./tools/lld/test/ELF/%lib.o" in the test directory.
llvm-svn: 362988
Fix buildbot failure on native AArch64 buildbot that does not have X86
backend compiled in.
Differential Revision: https://reviews.llvm.org/D63071
llvm-svn: 362926
This is implemented by the lld-link option -include:, just like
--require-defined. Contrary to --require-defined, the -u/--undefined
option allows the symbol to remain undefined in the end.
This should fix PR42121.
Differential Revision: https://reviews.llvm.org/D62876
llvm-svn: 362882
This works like /include, but is not fatal if the requested symbol
wasn't found. This allows implementing the GNU ld option -u.
Differential Revision: https://reviews.llvm.org/D62976
llvm-svn: 362881
Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.
However, when the symbol is re-exported under a new name, the linker has
to transfer the decorations from the exported symbol over to the new
name. This is implemented by taking the mangled symbol that was found in
the object and replacing the original symbol name with the export name.
Before this patch, LLD implemented the fuzzy search by adding an
undefined symbol with the unmangled name, and then during symbol
resolution, checking if similar mangled symbols had been added after the
last round of symbol resolution. If so, LLD makes the original symbol a
weak alias of the mangled symbol. Later, to get the original symbol
name, LLD would look through the weak alias and forward it on to the
import library writer, which copies the symbol decorations. This
approach doesn't work when bar is itself a weak alias, as is the case in
asan. It's especially bad when the aliasee of bar contains the string
"bar", consider "bar_default". In this case, we would end up exporting
the symbol "foo_default" when we should've exported just "foo".
To fix this, don't look through weak aliases to find the mangled name.
Save the mangled name earlier during fuzzy symbol lookup.
Fixes PR42074
Reviewers: mstorsjo, ruiu
Subscribers: thakis, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62984
llvm-svn: 362849
We create several types of synthetic sections for loadable partitions, including:
- The dynamic symbol table. This allows code outside of the loadable partitions
to find entry points with dlsym.
- Creating a dynamic symbol table also requires the creation of several other
synthetic sections for the partition, such as the dynamic table and hash table
sections.
- The partition's ELF header is represented as a synthetic section in the
combined output file, and will be used by llvm-objcopy to extract partitions.
Differential Revision: https://reviews.llvm.org/D62350
llvm-svn: 362819
Branch Target Identification (BTI) and Pointer Authentication (PAC) are
architecture features introduced in v8.5a and 8.3a respectively. The new
instructions have been added in the hint space so that binaries take
advantage of support where it exists yet still run on older hardware. The
impact of each feature is:
BTI: For executable pages that have been guarded, all indirect branches
must have a destination that is a BTI instruction of the appropriate type.
For the static linker, this means that PLT entries must have a "BTI c" as
the first instruction in the sequence. BTI is an all or nothing
property for a link unit, any indirect branch not landing on a valid
destination will cause a Branch Target Exception.
PAC: The dynamic loader encodes with PACIA the address of the destination
that the PLT entry will load from the .plt.got, placing the result in a
subset of the top-bits that are not valid virtual addresses. The PLT entry
may authenticate these top-bits using the AUTIA instruction before
branching to the destination. Use of PAC in PLT sequences is a contract
between the dynamic loader and the static linker, it is independent of
whether the relocatable objects use PAC.
BTI and PAC are independent features that can be combined. So we can have
several combinations of PLT:
- Standard with no BTI or PAC
- BTI PLT with "BTI c" as first instruction.
- PAC PLT with "AUTIA1716" before the indirect branch to X17.
- BTIPAC PLT with "BTI c" as first instruction and "AUTIA1716" before the
first indirect branch to X17.
The use of BTI and PAC in relocatable object files are encoded by feature
bits in the .note.gnu.property section in a similar way to Intel CET. There
is one AArch64 specific program property GNU_PROPERTY_AARCH64_FEATURE_1_AND
and two target feature bits defined:
- GNU_PROPERTY_AARCH64_FEATURE_1_BTI
-- All executable sections are compatible with BTI.
- GNU_PROPERTY_AARCH64_FEATURE_1_PAC
-- All executable sections have return address signing enabled.
Due to the properties of FEATURE_1_AND the static linker can tell when all
input relocatable objects have the BTI and PAC feature bits set. The static
linker uses this to enable the appropriate PLT sequence.
Neither -> standard PLT
GNU_PROPERTY_AARCH64_FEATURE_1_BTI -> BTI PLT
GNU_PROPERTY_AARCH64_FEATURE_1_PAC -> PAC PLT
Both properties -> BTIPAC PLT
In addition to the .note.gnu.properties there are two new command line
options:
--force-bti : Act as if all relocatable inputs had
GNU_PROPERTY_AARCH64_FEATURE_1_BTI and warn for every relocatable object
that does not.
--pac-plt : Act as if all relocatable inputs had
GNU_PROPERTY_AARCH64_FEATURE_1_PAC. As PAC is a contract between the loader
and static linker no warning is given if it is not present in an input.
Two processor specific dynamic tags are used to communicate that a non
standard PLT sequence is being used.
DTI_AARCH64_BTI_PLT and DTI_AARCH64_BTI_PAC.
Differential Revision: https://reviews.llvm.org/D62609
llvm-svn: 362793
When a function is excluded via comdat we shouldn't add it to the
final list of init functions.
Differential Revision: https://reviews.llvm.org/D62983
llvm-svn: 362769
Many -static/-no-pie/-shared/-pie applications linked against glibc or musl
should work with this patch. This also helps FreeBSD PowerPC64 to migrate
their lib32 (PR40888).
* Fix default image base and max page size.
* Support new-style Secure PLT (see below). Old-style BSS PLT is not
implemented, so it is not suitable for FreeBSD rtld now because it doesn't
support Secure PLT yet.
* Support more initial relocation types:
R_PPC_ADDR32, R_PPC_REL16*, R_PPC_LOCAL24PC, R_PPC_PLTREL24, and R_PPC_GOT16.
The addend of R_PPC_PLTREL24 is special: it decides the call stub PLT type
but it should be ignored for the computation of target symbol VA.
* Support GNU ifunc
* Support .glink used for lazy PLT resolution in glibc
* Add a new thunk type: PPC32PltCallStub that is similar to PPC64PltCallStub.
It is used by R_PPC_REL24 and R_PPC_PLTREL24.
A PLT stub used in -fPIE/-fPIC usually loads an address relative to
.got2+0x8000 (-fpie/-fpic code uses _GLOBAL_OFFSET_TABLE_ relative
addresses).
Two .got2 sections in two object files have different addresses, thus a PLT stub
can't be shared by two object files. To handle this incompatibility,
change the parameters of Thunk::isCompatibleWith to
`const InputSection &, const Relocation &`.
PowerPC psABI specified an old-style .plt (BSS PLT) that is both
writable and executable. Linkers don't make separate RW- and RWE segments,
which causes all initially writable memory (think .data) executable.
This is a big security concern so a new PLT scheme (secure PLT) was developed to
address the security issue.
TLS will be implemented in D62940.
glibc older than ~2012 requires .rela.dyn to include .rela.plt, it can
not handle the DT_RELA+DT_RELASZ == DT_JMPREL case correctly. A hack
(not included in this patch) in LinkerScript.cpp addOrphanSections() to
work around the issue:
if (Config->EMachine == EM_PPC) {
// Older glibc assumes .rela.dyn includes .rela.plt
Add(In.RelaDyn);
if (In.RelaPlt->isLive() && !In.RelaPlt->Parent)
In.RelaDyn->getParent()->addSection(In.RelaPlt);
}
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62464
llvm-svn: 362721
We were not previously testing the comdat exclusion in bitcode objects
because we were linking two copies of the .bc file and the
`linkonce_odr` linkage type was removing the duplicate `_start` at
the LTO stage.
Now we link an bitcode and non-bitcode version both of which contains a
copy of _start. We link them in both orders, which means this test will
fail if comdat exclusion is not working correctly in bitcode parsing.
Differential Revision: https://reviews.llvm.org/D62923
llvm-svn: 362650
With r362638, llc doesn't support -relocation-model=pic with non-Emscripten
triples. Update these tests in lld which use -relocation-model=pic to also
use Emscripten triples.
llvm-svn: 362645
Although many relocatable objects will have a single
GNU_PROPERTY_X86_FEATURE_1_AND in the .note.gnu.property section it is
permissible to have more than one, and there are tests in ld.bfd that use
it. The behavior that ld.bfd follows is to set the feature bit for a
relocatable object if any of the GNU_PROPERTY_X86_FEATURE_1_AND
have the feature bit set.
Differential Revision: https://reviews.llvm.org/D62862
llvm-svn: 362591
The age field is only there to say how many times an OBJ or a PDB was incrementally linked. It shouldn't be used to validate the link between the OBJ and the PDB.
Differential Revision: https://reviews.llvm.org/D62837
llvm-svn: 362572
Summary:
With -r or --emit-relocs, we warn `STT_SECTION symbol should be defined`
on relocations to discarded section symbol. This was added as an error
in rLLD319404, but was not so effective before D61583 (it turned the
error to a warning).
Relocations from .eh_frame .debug* .zdebug* .gcc_except_table to
discarded .text are very common and somewhat expected. Don't warn/error
on them. As a reference, ld.bfd has a similar logic in
_bfd_elf_default_action_discarded() to allow these cases.
Delete invalid-undef-section-symbol.test because what it intended to
check is now covered by the updated comdat-discarded-reloc.s
Delete relocatable-eh-frame.s because we allow relocations from
.eh_frame as a special case now.
Reviewers: grimar, phosek, ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62840
llvm-svn: 362497
Summary:
- Fixes inline call frame line table display in windbg.
- Improve llvm-pdbutil to dump extra file ids.
- Warn on unknown subsections so we don't have this kind of bug in the
future.
Reviewers: inglorion, akhuang, aganea
Subscribers: eraman, zturner, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62701
llvm-svn: 362429
We need to have all input files ready before doing debuginfo type merging.
This patch is moving the late PDB type server discovery much earlier in the process, when the explicit inputs (OBJs, LIBs) are loaded.
The short term goal is to parallelize type merging.
Differential Revision: https://reviews.llvm.org/D60095
llvm-svn: 362393
The following abstract relocation types (RelExpr) are PPC64 ELFv2 ABI specific,
not used by PPC32. So rename them to prevent confusion when the PPC32 port is improved.
* R_PPC_CALL R_PPC_CALL_PLT:
R_PPC_CALL_PLT represents R_PPC64_REL14 and R_PPC64_REL24.
If the function is not preemptable, R_PPC_CALL_PLT can be optimized to R_PPC_CALL:
the formula adjusts the symbol VA from the global entry point to the local entry point.
* R_PPC_TOC: represents R_PPC64_TOC. We don't have a test. Add one to ppc64-relocs.s
Rename it to R_PPC64_TOCBASE because `@tocbase` is the assembly form.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62800
llvm-svn: 362359
In ELF v2 ABI, R_PPC64_GOT_DTPREL16* are not relaxed.
This family of relocation types are used for variables outside of 2GiB
of the TLS block. 2 instructions cannot materialize a DTPREL offset that
is not 32-bit.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62737
llvm-svn: 362357
Fixes the remaining issue of PR41673 after D61186: with `/DISCARD/ { ... } :NONE`,
we may create an output section named `/DISCARD/`.
Note, if an input section is named `/DISCARD/`, ld.bfd discards it but
lld keeps it. It is probably not worth copying this behavior as it is unrealistic.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62768
llvm-svn: 362356
(1) {gcc,clang} -fuse-ld=bfd -pie -fPIE -nostdlib a.c => .interp created
(2) {gcc,clang} -fuse-ld=lld -pie -fPIE -nostdlib a.c => .interp not created
(3) {gcc,clang} -fuse-ld=lld -pie -fPIE -nostdlib a.c a.so => .interp created
The inconsistency of (2) is due to the condition `!Config->SharedFiles.empty()`.
To make lld behave more like ld.bfd, we could change the condition to:
Config->HasDynSymTab && !Config->DynamicLinker.empty() && Script->needsInterpSection();
However, that would bring another inconsistency as can be observed with:
(4) {gcc,clang} -fuse-ld=bfd -no-pie -nostdlib a.c => .interp not created
So instead, use `!Config->DynamicLinker.empty() && Script->needsInterpSection()`,
which is both simple and consistent in these cases.
The inconsistency of (4) likely originated from ld.bfd and gold's choice to have a default --dynamic-linker.
Their condition to create .interp is ANDed with (not -shared).
Since lld doesn't have a default --dynamic-linker,
compiler drivers (gcc/clang) don't pass --dynamic-linker for -shared,
and direct ld users are not supposed to specify --dynamic-linker for -shared,
we do not need the condition !Config->Shared.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62765
llvm-svn: 362355
Delete aarch64-got.s because it is covered by aarch64-tls-iele.s
Merge got-aarch64.s into aarch64-fpic-got.s by adding disassembly to the latter
Create aarch64-gnu-ifunc-nonpreemptable to unify aarch64-gnu-ifunc3.s (position-dependent executable) and aarch64-gnu-ifunc-address-pie.s (PIE)
Rename aarch64-got-reloc.s to aarch64-got-weak-undef.s
Add --no-show-raw-insn to llvm-objdump -d RUN lines
Add -pie test to arch64-tls-iele.s
Delete aarch64-tls-pie.s: it is covered by arch64-tls-iele.s and aarch64-tls-le.s
Rename aarch64-copy2.s to aarch64-nopic-plt.s: "copy2" gives false impression that the test is related to copy relocation
llvm-svn: 362294
The test (the only test that checks getLinkerScriptLocation()) deleted
by r358652 can be restored by replacing R_X86_64_PLT32 with
R_X86_64_PC32, and changing -pie to -shared (preemptable). Then, the
symbol will not be a link-time constant and a -fPIC error will be
issued.
llvm-svn: 362207
Summary:
Add the names of the input files responsible for each error to the
messages.
Reviewers: sbc100, azakai
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62704
llvm-svn: 362162
This is a leftover from r325379.
The intention of this test was to check in a non-pic link, R_X86_64_PC32
to a STT_FUNC created a PLT. However, after the llvm-mc change in
r325569, this code path is no longer exercised. Use the r325379 trick to
keep testing R_X86_64_PC32.
llvm-svn: 362095
For the Local Dynamic case of TLSDESC, _TLS_MODULE_BASE_ is defined as a
special TLS symbol that makes:
1) Without relaxation: it produces a dynamic TLSDESC relocation that
computes 0. Adding @dtpoff to access a TLS symbol.
2) With LD->LE relaxation: _TLS_MODULE_BASE_@tpoff = 0 (lowest address in
the TLS block). Adding @tpoff to access a TLS symbol.
For 1), this saves dynamic relocations and GOT slots as otherwise
(General Dynamic) we would create an R_X86_64_TLSDESC and reserve two
GOT slots for each symbol.
Add ElfSym::TlsModuleBase and change the signature of getTlsTpOffset()
to special case _TLS_MODULE_BASE_.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62577
llvm-svn: 362078
There's no guarantee that the other partition will be loaded, so it
can't be reused.
Differential Revision: https://reviews.llvm.org/D62365
llvm-svn: 361926
This change causes us to read partition specifications from partition
specification sections and split output sections into partitions according
to their reachability from partition entry points.
This is only the first step towards a full implementation of partitions. Later
changes will add additional synthetic sections to each partition so that
they can be loaded independently.
Differential Revision: https://reviews.llvm.org/D60353
llvm-svn: 361925
This handles two initial relocation types R_X86_64_GOTPC32_TLSDESC and
R_X86_64_TLSDESC_CALL, as well as the GD->LE and GD->IE relaxations.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62513
llvm-svn: 361911
We need to have all input files ready before doing debuginfo type merging.
This patch is moving the late PDB type server discovery much earlier in the process, when the explicit inputs (OBJs, LIBs) are loaded.
The short term goal is to parallelize type merging.
Differential Revision: https://reviews.llvm.org/D60095
llvm-svn: 361842
This is implemented by creating Undefined (instead of Defined) for such
local STT_SECTION symbols. It allows us to catch errors when there are
relocations to such discarded sections (e.g. in PR41693, ld.bfd and gold
error but we don't). Updated comdat-discarded-error.s checks we emit
friendly error message.
For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error
"STT_SECTION symbol should be defined" because the section .eh_frame
refers to is now an Undefined instead of a Defined.
So I have to change `error()` to `warn()` to retain the output.
rLLD361144 inadvertently enabled the error for --gdb-index
(in LLDDwarfObj<ELFT>::findAux()).
Relocations from .debug_info (not in comdat) to .text.* (in comdat) for
DW_AT_low_pc are common. If an .text.* was discarded, rLLD361144 would error,
which was unexpected. (Note, if we don't error as this patch does,
InputSection::relocateNonAlloc() will resolve such relocations).
llvm-svn: 361830
This is implemented by creating Undefined (instead of Defined) for such
local STT_SECTION symbols. It allows us to catch errors when there are
relocations to such discarded sections (e.g. in PR41693, ld.bfd and gold
error but we don't). Updated comdat-discarded-error.s checks we emit
friendly error message.
For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error
"STT_SECTION symbol should be defined" because the section .eh_frame
refers to is now an Undefined instead of a Defined.
So I have to change `error()` to `warn()` to retain the output.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61583
llvm-svn: 361792
When function signatures don't match and the undefined function is not
called directly (i.e. only has its address taken) we don't issue a
warning or create a runtime thunk for the undefined function.
Instead in this case we simply use the defined version of the function.
This is possible since checking signatures of dynamic calls happens
at runtime so any invalid usage will still result in a runtime error.
This is needed to allow C++ programs to link without generating
warnings. Its not uncommon in C++ for vtables to be populated by
function address whee the signature of the function is not known in the
compilation unit. In this case clang declares the method as void(void)
and relies on the vtable caller casting the data back to the correct
signature.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=40412
Differential Revision: https://reviews.llvm.org/D62153
llvm-svn: 361678
Shaves another 8 bytes off of SectionChunk, the most commonly allocated
type in LLD.
These indices are only valid after we've assigned chunks to output
sections and removed empty sections, so do that in a new pass.
Reviewers: ruiu, aganea
Differential Revision: https://reviews.llvm.org/D62356
llvm-svn: 361657
This can be useful for post-link tools and for testing. Sometimes
it can be useful to produces a regular executable but with relocations
preserved.
Differential Revision: https://reviews.llvm.org/D62378
llvm-svn: 361635
Patch by Stefan Schmidt.
This adds the /filealign parameter to lld, which allows to specify the
section alignment in the output file (as it does on Microsoft's
link.exe).
This is required to be able to load dynamically linked libraries on the
original Xbox, where the debugger monitor expects the section alignment
in the file to be the same as in memory.
llvm-svn: 361634
GNU readelf tool prints slightly different dynamic table "header" and
surrounds dynamic tag names by brackets. This patch implements the same
formatting for GNU-style output of the `llvm-readobj`.
LLVM
```
DynamicSection [ (13 entries)
Tag Type Name/Value
0x00000006 SYMTAB 0x168
...
]
```
GNU
```
Dynamic section at offset 0x1d0 contains 13 entries:
Tag Type Name/Value
0x00000006 (SYMTAB) 0x168
...
```
Differential Revision: https://reviews.llvm.org/D62256
llvm-svn: 361633
OptTable treats arguments starting with / that aren't a known option
as filenames. This means lld-link's and clang-cl's typo correction for
unknown flags didn't do spell checking for misspelled options that start
with /.
I first tried changing OptTable, but that got pretty messy, see PR41787
comments 2 and 3.
Instead, let lld-link's and clang's (including clang-cl's) "file not
found" diagnostic check if a non-existent file looks like it could be a
mis-spelled option, and if so add a "did you mean" suggestion to the
"file not found" diagnostic.
While here, make formatting of a few diagnostics a bit more
self-consistent.
Fixes PR41787.
Differential Revision: https://reviews.llvm.org/D62276
llvm-svn: 361518
The previous patch lost the call to PowerOf2Ceil, which causes LLD to
crash when handling common symbols with a non-power-of-2 size. I tweaked
the existing common.test to make the bsspad16 common symbol be 15 bytes
to add coverage for this case.
llvm-svn: 361426
Rather than report "undefined symbol: ", give more informative message
about the object file that defines the discarded section.
In particular, PR41133, if the section is a discarded COMDAT, print the
section group signature and the object file with the prevailing
definition. This is useful to track down some ODR issues.
We need to
* add `uint32_t DiscardedSecIdx` to Undefined for this feature.
* make ComdatGroups public and change its type to DenseMap<CachedHashStringRef, const InputFile *>
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D59649
llvm-svn: 361359
This reverts commit 7804dbddcc.
This change broke a bunch of tests of the WebAssembly waterfall.
Will hopefully reland with increased test coverage.
llvm-svn: 361273
--reproduce is a convenient option for debugging. If you invoke lld
with `--reproduce=repro.tar`, it creates `repro.tar` with all input
files and the command line options given to the linker, so that it is
very easy to run lld with the exact same inputs.
ELF and Windows lld have this option.
This patch add that option to lld/wasm.
Differential Revision: https://reviews.llvm.org/D62170
llvm-svn: 361244
For memory5.test, ld.bfd appears to ignore `. += 0x2000;`, so the test was testing
a wrong behavior. After deleting the code added in rLLD336335, we match ld.bfd and thus fix PR41357.
PR37836 (memory4.test) seems to have been fixed by another change.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62177
llvm-svn: 361228
For a reference to a local symbol, ld.bfd and gold error if the symbol
is defined in a discarded section but accept it if the symbol is
undefined. This inconsistent behavior seems unnecessary for us (it
probably makes sense for them as they differentiate local/global
symbols, the error would mean more code).
Catch such errors. Symbol index 0 may be used by marker relocations,
e.g. R_*_NONE R_ARM_V4BX. Don't error on them.
The difference from D61563 (which caused msan failure) is we don't call
Sym.computeBinding() on local symbols - VersionId is uninitialized.
llvm-svn: 361213
This patch is a fix for https://bugs.llvm.org/show_bug.cgi?id=41804.
We try to solve the precedence of user-specified symbol ordering file and C3 ordering provided as call graph. It deals with two case:
(1) When both --symbol-ordering-file=<file> and --call-graph-order-file=<file> are present, whichever flag comes later will take precedence.
(2) When only --symbol-ordering-file=<file> is present, it takes precedence over implicit call graph (CGProfile) generated by CGProfilePass enabled in new pass manager.
llvm-svn: 361190
We currently sort dynamic relocations by (!is_relative,symbol_index).
Add r_offset as the third key. This makes `readelf -r` debugging easier
(relocations to the same symbol are ordered by r_offset).
Refactor the test combreloc.s (renamed from combrelocs.s) to check
R_X86_64_RELATIVE, and delete --expand-relocs.
The difference from the reverted D61477 is that we keep !is_relative as
the first key. In local dynamic TLS model, DTPMOD (e.g.
R_ARM_TLS_DTPMOD32 R_X86_64_DTPMOD and R_PPC{,64}_DTPMOD) may use 0 as
the symbol index.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D62141
llvm-svn: 361164
This reverts commit r361144. It causes a use-of-uninitialized-value in
maybeReportUndefined at llvm/tools/lld/ELF/Relocations.cpp:682, as
detected by MemorySanitizer when local-undefined-symbol.s test is run.
llvm-svn: 361162
This reverts commit r361125. This linker change breaks shared libraries
in some subtle way on x86_64. (Specifically, gold segfaults when
loading the LLVMgold.so plugin linked with lldb with this patch.)
llvm-svn: 361150
For R_TLS:
1) Delete Sym.isTls() . The assembler ensures the symbol is STT_TLS.
If not (the input is broken), we would crash (dereferencing null Out::TlsPhdr).
2) Change Sym.isUndefWeak() to Sym.isUndefined(), otherwise with --noinhibit-exec
we would still evaluate the symbol and crash.
3) Return A if the symbol is undefined. This is PR40570.
The case is probably unrealistic but returning A matches R_ABS and the
behavior of several dynamic loaders.
R_NEG_TLS is obsoleted Sun TLS we don't fully support, but
R_RELAX_TLS_GD_TO_LE_NEG is still used by GD->LE relaxation (subl $var@tpoff,%eax).
They should add the addend. Unfortunately I can't test it as compilers don't seem to generate non-zero implicit addends.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62098
llvm-svn: 361146
For a reference to a local symbol, ld.bfd and gold error if the symbol
is defined in a discarded section but accept it if the symbol is
undefined. This inconsistent behavior seems unnecessary for us (it
probably makes sense for them as they differentiate local/global
symbols, the error would mean more code).
Weaken the condition to getSymbol(Config->IsMips64EL) == 0 to catch such
errors. The symbol index can be 0 (e.g. R_*_NONE R_ARM_V4BX) and we shouldn't error on them.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61563
llvm-svn: 361144
Fixes PR41692.
We currently sort dynamic relocations by (!is_relative,symbol_index).
Change it to (symbol_index,r_offset). We still place relative
relocations first because R_*_RELATIVE are the only dynamic relocations
with 0 symbol index (except on MIPS, which doesn't use DT_REL[A]COUNT
anyway).
This makes `readelf -r` debugging easier (relocations to the same symbol
are ordered by r_offset).
Refactor the test combreloc.s (renamed from combrelocs.s) to check
R_X86_64_RELATIVE, and delete --expand-relocs.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61477
llvm-svn: 361125
Otherwise, we may set IsPreemptible (e.g. --dynamic-list) then clear it
(in replaceCommonSymbols()).
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62107
llvm-svn: 361122
This reverts D53906.
D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the
static TLS layout compatible with Android Bionic's ELF TLS. However,
this may cause glibc ARM/AArch64 programs to crash (see PR41527).
The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The
remainder is normally 0 but may be non-zero with the hack in place. The
problem is that we increase PT_TLS's p_align after OutputSections'
addresses are fixed (assignAddress()). It is possible that
p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0.
For a thread local variable defined in the executable, lld computed TLS
offset (local exec) is different from glibc computed TLS offset from
another module (initial exec/generic dynamic). Note: PR41527 said the
bug affects initial exec but actually generic dynamic is affected as
well.
(glibc is correct in that it compute offsets that satisfy
`offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement.
This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but
that is just because they (and lld) incorrectly compute offsets that
satisfy `offset%p_align = 0` instead.)
Android developers are fine to revert this patch, carry this patch in
their tree before figuring out a long-term solution (e.g. a dummy .tdata
with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is
now insignificant after D62059).
Reviewed By: rprichard, srhines
Differential Revision: https://reviews.llvm.org/D62055
llvm-svn: 361090
After D62059, we don't align p_memsz of PT_TLS to p_align. The
getRelocTargetVA formula should align it instead.
It becomes clear that R_NEG_TLS and R_TLS are opposite from each other.
In i386-tls-le-align.s, I put ret after call ___tls_get_addr@plt as
otherwise ld.bfd would reject the relaxation:
TLS transition from R_386_TLS_GD to R_386_TLS_LE_32 against `a' at 0x3 in section `.text' failed
llvm-svn: 361088
On Elf*_Rel targets, for a relocation to a section symbol, an R_ABS is
added which will be used by relocateOne() to compute the implicit
addend.
Addends of R_*_NONE should be ignored, so don't emit an R_ABS.
This fixes crashes on X86 and ARM because their relocateOne() do not
handle R_*_NONE.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D62052
llvm-svn: 361036
The code was added in r252352, probably to address some layout issues.
Actually PT_TLS's p_memsz doesn't need to be aligned on either variant.
ld.bfd doesn't do that.
In case of larger alignment (e.g. 64 for Android Bionic on AArch64, see
D62055), this may make the overhead smaller.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62059
llvm-svn: 361029
Libtool concludes that the linker doesn't support shared libraries,
unless this flag is listed in the output of --help.
Differential Revision: https://reviews.llvm.org/D62053
llvm-svn: 361017
When integrating PDB output in mingw targeting build systems, it
might be a lot of extra work to specify unique file names for
the pdb output. Therefore allow omitting the actual file name
and let it implicitly be the same name as the linker output, with
a pdb extension.
As the current form of the pdb option takes a separate parameter value,
e.g. "-pdb out.pdb", it is impractical to leave out the parameter value.
Therefore, introduce a second syntax for the option, with an equals
sign, like -pdb=out.pdb, where the value easily can be omitted.
The form -pdb= for requesting pdb files with an implicit name should
work fine, even though it looks a bit unconventional in that form.
Differential Revision: https://reviews.llvm.org/D62004
llvm-svn: 361014
Change R_{386,AARCH64}_NONE yaml2obj tests/icf10.test to use assembly
Add relocation-none-{arm,x86_64}.s.
Check the referenced section survives under --gc-sections.
Check -r copies R_X86_64_NONE R_AARCH64_NONE. (Elf*_Rel arches currently have a bug)
Delete the dtrace tests as they are covered by the R_X86_64_NONE test.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62051
llvm-svn: 361013
This patch implements a limited form of autolinking primarily designed to allow
either the --dependent-library compiler option, or "comment lib" pragmas (
https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in
C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically
add the specified library to the link when processing the input file generated
by the compiler.
Currently this extension is unique to LLVM and LLD. However, care has been taken
to design this feature so that it could be supported by other ELF linkers.
The design goals were to provide:
- A simple linking model for developers to reason about.
- The ability to to override autolinking from the linker command line.
- Source code compatibility, where possible, with "comment lib" pragmas in other
environments (MSVC in particular).
Dependent library support is implemented differently for ELF platforms than on
the other platforms. Primarily this difference is that on ELF we pass the
dependent library specifiers directly to the linker without manipulating them.
This is in contrast to other platforms where they are mapped to a specific
linker option by the compiler. This difference is a result of the greater
variety of ELF linkers and the fact that ELF linkers tend to handle libraries in
a more complicated fashion than on other platforms. This forces us to defer
handling the specifiers to the linker.
In order to achieve a level of source code compatibility with other platforms
we have restricted this feature to work with libraries that meet the following
"reasonable" requirements:
1. There are no competing defined symbols in a given set of libraries, or
if they exist, the program owner doesn't care which is linked to their
program.
2. There may be circular dependencies between libraries.
The binary representation is a mergeable string section (SHF_MERGE,
SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES
(0x6fff4c04). The compiler forms this section by concatenating the arguments of
the "comment lib" pragmas and --dependent-library options in the order they are
encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs
sections with the normal mergeable string section rules. As an example, #pragma
comment(lib, "foo") would result in:
.section ".deplibs","MS",@llvm_dependent_libraries,1
.asciz "foo"
For LTO, equivalent information to the contents of a the .deplibs section can be
retrieved by the LLD for bitcode input files.
LLD processes the dependent library specifiers in the following way:
1. Dependent libraries which are found from the specifiers in .deplibs sections
of relocatable object files are added when the linker decides to include that
file (which could itself be in a library) in the link. Dependent libraries
behave as if they were appended to the command line after all other options. As
a consequence the set of dependent libraries are searched last to resolve
symbols.
2. It is an error if a file cannot be found for a given specifier.
3. Any command line options in effect at the end of the command line parsing apply
to the dependent libraries, e.g. --whole-archive.
4. The linker tries to add a library or relocatable object file from each of the
strings in a .deplibs section by; first, handling the string as if it was
specified on the command line; second, by looking for the string in each of the
library search paths in turn; third, by looking for a lib<string>.a or
lib<string>.so (depending on the current mode of the linker) in each of the
library search paths.
5. A new command line option --no-dependent-libraries tells LLD to ignore the
dependent libraries.
Rationale for the above points:
1. Adding the dependent libraries last makes the process simple to understand
from a developers perspective. All linkers are able to implement this scheme.
2. Error-ing for libraries that are not found seems like better behavior than
failing the link during symbol resolution.
3. It seems useful for the user to be able to apply command line options which
will affect all of the dependent libraries. There is a potential problem of
surprise for developers, who might not realize that these options would apply
to these "invisible" input files; however, despite the potential for surprise,
this is easy for developers to reason about and gives developers the control
that they may require.
4. This algorithm takes into account all of the different ways that ELF linkers
find input files. The different search methods are tried by the linker in most
obvious to least obvious order.
5. I considered adding finer grained control over which dependent libraries were
ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this
is not necessary: if finer control is required developers can fall back to using
the command line directly.
RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.
Differential Revision: https://reviews.llvm.org/D60274
llvm-svn: 360984
The change broke some scenarios where debug information is still
needed, although MarkLive cannot see it, including the
Chromium/Android build. Reverting to unbreak that build.
llvm-svn: 360955
Module IDs can appear in diagnostic messages.
This patch adds some auxiliary symbols to improve their readability.
Differential Revision: https://reviews.llvm.org/D61857
llvm-svn: 360858
The tracing goes to stdout so this is not needed.
Also remove the "not" from the final check in ELF/trace-symbols.s.
According the comment the check is that we don't crash, so we should
be checking for success here. Previously this step is error'ing with
undefined symbols because it didn't include all the needed objects.
Differential Revision: https://reviews.llvm.org/D61928
llvm-svn: 360794
But don't apply comdat groups when loading the LTO object files.
This is basically the same logic used by the ELF linker.
Differential Revision: https://reviews.llvm.org/D61924
llvm-svn: 360782
Patch by Mark Johnston!
Summary:
When the option is configured, ifunc calls do not go through the PLT;
rather, they appear as regular function calls with relocations
referencing the ifunc symbol, and the resolver is invoked when
applying the relocation. This is intended for use in freestanding
environments where text relocations are permissible and is incompatible
with the -z text option. The option is motivated by ifunc usage in the
FreeBSD kernel, where ifuncs are used to elide CPU feature flag bit
checks in hot paths. Instead of replacing the cost of a branch with that
of an indirect function call, the -z ifunc-noplt option is used to ensure
that ifunc calls carry no hidden overhead relative to normal function
calls.
Test Plan:
I added a couple of regression tests and tested the FreeBSD kernel
build using the latest lld sources.
To demonstrate the effects of the change, I used a micro-benchmark
which results in frequent invocations of a FreeBSD kernel ifunc. The
benchmark was run with and without IBRS enabled, and with and without
-zifunc-noplt configured. The observed speedup is small and consistent,
and is significantly larger with IBRS enabled:
https://people.freebsd.org/~markj/ifunc-noplt/noibrs.txthttps://people.freebsd.org/~markj/ifunc-noplt/ibrs.txt
Reviewed By: ruiu, MaskRay
Differential Revision: https://reviews.llvm.org/D61613
llvm-svn: 360685
See D61891: llvm had a bug that might create invalid (DW_AT_low_pc,DW_AT_high_pc) pairs or range list entries due to missing DW_AT_addr_base.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61889
llvm-svn: 360679
The -n (--nmagic) disables page alignment, and acts as a -Bstatic
The -N (--omagic) does what -n does but also marks the executable segment as
writeable. As page alignment is disabled headers are not allocated unless
explicit in the linker script.
To disable page alignment in LLD we choose to set the page sizes to 1 so
that any alignment based on the page size does nothing. To set the
Target->PageSize to 1 we implement -z common-page-size, which has the side
effect of allowing the user to set the value as well.
Setting the page alignments to 1 does mean that any use of
CONSTANT(MAXPAGESIZE) or CONSTANT(COMMONPAGESIZE) in a linker script will
return 1, unlike in ld.bfd. However given that -n and -N disable paging
these probably shouldn't be used in a linker script where -n or -N is in
use.
Differential Revision: https://reviews.llvm.org/D61688
llvm-svn: 360593
These yaml test cases appear to have been affected by PR41836
Right now what happens is that these empty .bss sections are merged into
.data, then the .data output section ends up having a zero virtual size,
and it is discarded from the output after addresses are assigned.
However, we've already assigned OutputSections to Chunks, so we don't
correctly report the zero-sized chunks that were in there as having been
discarded. Soon, we will report them as discarded, so these test cases
need to be updated to have a non-zero size so they aren't discarded.
llvm-svn: 360476
Add support for ".hidden" ".internal" ".protected" and " 0x%02x" for
other st_other bits used by some architectures.
Reviewed By: sfertile
Differential Revision: https://reviews.llvm.org/D61718
llvm-svn: 360439
Suggested by Sean Fertile and Peter Smith.
Thunk section spacing decrease the total number of thunks. I measured a
decrease of 1% or less in some large programs, with no perceivable
slowdown in link time. Override getThunkSectionSpacing() to enable it.
0x2000000 is the farthest point R_PPC64_REL24 can reach. I tried several
numbers and found 0x2000000 works the best. Numbers near 0x2000000 work
as well but let's just use the simpler number.
As demonstrated by the updated tests, this essentially changes placement
of most thunks to the end of the output section. We leverage this
property to fix PR40740 reported by Alfredo Dal'Ava Júnior:
The output section .init consists of input sections from several object
files (crti.o crtbegin.o crtend.o crtn.o). Sections other than the last
one do not have a terminator. With this patch, we create the thunk after
the last .init input section and thus fix the issue. This is not
foolproof but works quite well for such sections (with no terminator) in
practice.
Reviewed By: ruiu, sfertile
Differential Revision: https://reviews.llvm.org/D61720
llvm-svn: 360405
The current PIC model for WebAssembly is more like ELF in that it
allows symbol interposition.
This means that more functions end up being addressed via the GOT
and fewer directly added to the wasm table.
One effect is a reduction in the number of wasm table entries similar
to the previous attempt in https://reviews.llvm.org/D61539 which was
reverted.
Differential Revision: https://reviews.llvm.org/D61772
llvm-svn: 360402
for (InputFile *F : Files)
Symtab->addFile<ELFT>(F); // if there is a duplicate symbol error
...
Target = getTarget();
When parsing .debug_info in the object file (for better diagnostics),
DWARF.cpp findAux may dereference the null pointer Target
auto *DR = dyn_cast<Defined>(&File->getRelocTargetSym(Rel));
if (!DR) {
// Broken debug info may point to a non-defined symbol,
// some asan object files may also contain R_X86_64_NONE
RelType Type = Rel.getType(Config->IsMips64EL);
if (Type != Target->NoneRel) /// Target is null
Move the assignment of Target to an earlier place to fix this.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61712
llvm-svn: 360305
Summary:
When using lld-link to build static libraries containing object files
with module assembly, the program would crash with "Assertion `T &&
T->hasMCAsmParser()' failed". This change causes the code in lld-link
that initialized Targets, TargetInfos, and AsmParsers (which already
existed) to be run before entering the lib building path (which needs
it). This avoids the error (and is what llvm-lib and llvm-ar do, too).
Fixes PR41803.
Reviewers: ruiu, rnk, hans
Reviewed By: ruiu
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61699
llvm-svn: 360295
Use `ld` and `daddiu` instructions in MIPS64 PLT records. That fixes a
segmentation fault.
Patch by Qiao Pengcheng.
Differential Revision: https://reviews.llvm.org/D61586
llvm-svn: 360187
When generating PIC output only relocations of type
R_WASM_TABLE_INDEX_REL_SLEB should generate table entries.
R_WASM_TABLE_INDEX_I32 get resolved at runtime via the auto-generated
__wasm_apply_relocs functions.
R_WASM_TABLE_INDEX_SLEB are not allowed in PIC code.
Differential Revision: https://reviews.llvm.org/D61539
llvm-svn: 360165
For lld-link, unknown '/'-style flags are treated as filenames on POSIX
systems, so only '-'-style flags get typo correction for now. This
matches clang-cl.
PR37006.
Differential Revision: https://reviews.llvm.org/D61443
llvm-svn: 360145
This is based on D54720 by Sean Fertile.
When accessing a global symbol which is not defined in the translation unit,
compilers will generate instructions that load the address from the toc entry.
If the symbol is defined, non-preemptable, and addressable with a 32-bit
signed offset from the toc pointer, the address can be computed
directly. e.g.
addis 3, 2, .LC0@toc@ha # R_PPC64_TOC16_HA
ld 3, .LC0@toc@l(3) # R_PPC64_TOC16_LO_DS, load the address from a .toc entry
ld/lwa 3, 0(3) # load the value from the address
.section .toc,"aw",@progbits
.LC0: .tc var[TC],var
can be relaxed to
addis 3,2,var@toc@ha # this may be relaxed to a nop,
addi 3,3,var@toc@l # then this becomes addi 3,2,var@toc
ld/lwa 3, 0(3) # load the value from the address
We can delete the test ppc64-got-indirect.s as its purpose is covered by
newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s
Reviewed By: ruiu, sfertile
Differential Revision: https://reviews.llvm.org/D60958
llvm-svn: 360112
The only known user of this relocation type and symbol type is
the debug info sections, but we were not testing the `--relocatable`
output path.
This change adds a minimal test case to cover relocations against
section symbols includes `--relocatable` output.
Differential Revision: https://reviews.llvm.org/D61623
llvm-svn: 360110
Summary:
While the generic ABI requires notes to be 8-byte aligned in ELF64, many
vendor-specific notes (from Linux, NetBSD, Solaris, etc) use 4-byte
alignment.
In a PT_NOTE segment, if 4-byte aligned notes are followed by an 8-byte
aligned note, the possible 4-byte padding may make consumers fail to
parse the 8-byte aligned note. See PR41000 for a recent report about
.note.gnu.property (NT_GNU_PROPERTY_TYPE_0).
(Note, for NT_GNU_PROPERTY_TYPE_0, the consumers should probably migrate
to PT_GNU_PROPERTY, but the alignment issue affects other notes as well.)
To fix the issue, don't mix notes with different alignments in one
PT_NOTE. If compilers emit 4-byte aligned notes before 8-byte aligned
notes, we'll create at most 2 segments.
sh_size%sh_addralign=0 is actually implied by the rule for linking
unrecognized sections (in generic ABI), so we don't have to check that.
Notes that match in name, type and attribute flags are concatenated into
a single output section. The compilers have to ensure
sh_size%sh_addralign=0 to make concatenated notes parsable.
An alternative approach is to create a PT_NOTE for each SHT_NOTE, but
we'll have to incur the sizeof(Elf64_Phdr)=56 overhead every time a new
note section is introduced.
Reviewers: ruiu, jakehehrlich, phosek, jhenderson, pcc, espindola
Subscribers: emaste, arichardson, krytarowski, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61296
llvm-svn: 359853
As a side benefit, lld-link now reports more than one duplicate resource
entry before exiting with an error even if the new flag is not passed.
llvm-svn: 359829
Summary:
The gold plugin behavior (creating empty index files for lazy bitcode
files) was added in D46034, but it missed the case when there is no
non-lazy bitcode files, e.g.
ld.lld -shared crti.o crtbeginS.o --start-lib bitcode.o --end-lib ...
crti.o crtbeginS.o are not bitcode, but our distributed build system
wants bitcode.o.thinlto.bc to confirm all expected outputs are created
based on all of the modules provided to the linker.
Differential Revision: https://reviews.llvm.org/D61420
llvm-svn: 359788
This improves readability and the behavior is consistent with GNU objdump.
The new test test/tools/llvm-objdump/X86/disassemble-section-name.s
checks we print newlines before and after "Disassembly of section ...:"
Differential Revision: https://reviews.llvm.org/D61127
llvm-svn: 359668
Also change some options that have different semantics (cause confusion) in llvm-readelf mode:
-s => -S
-t => --symbols
-sd => --section-data
llvm-svn: 359651
/DISCARD/ output sections were being treated as orphans. As a result, if
a /DISCARD/ output section has been assigned a PHDR, it could cause
incorrect assignment of sections to segments.
Differential Revision: https://reviews.llvm.org/D61186
llvm-svn: 359565
This is a follow up to r358979 which made findOrphanPos only consider
live sections. Unfortunately, this required change to getRankProximity,
used by findOrphanPos, was missed.
Differential Revision: https://reviews.llvm.org/D61197
llvm-svn: 359554
This is https://bugs.llvm.org//show_bug.cgi?id=38750.
If script references empty sections in LOADADDR/ADDR commands
.empty : { *(.empty ) }
.text : AT(LOADADDR (.empty) + SIZEOF (.empty)) { *(.text) }
then an empty section will be removed and LOADADDR/ADDR will evaluate to null.
It is not that user may expect from using of the generic script, what is a common case.
Differential revision: https://reviews.llvm.org/D54621
llvm-svn: 359279
The code we generate for applying data relocations at runtime omitted
the symbols with GOT entries.
Also refactor the code to reduce duplication.
Differential Revision: https://reviews.llvm.org/D61111
llvm-svn: 359207
This removes one more binary object from the inputs and fixes the
test case description.
Previously it said that:
"symbol-index.elf has incorrect type of .symtab section.
There is no symbol bodies because of that and any symbol index becomes incorrect."
But the real reason of the failture was not the incorrect type of a symbol table,
but invalid index of the symbol used in a relocation, what happened because
previous test tried to read .symtab as a SHT_RELA section.
llvm-svn: 359197
r191276 added this to old LLD, but it never made it to new LLD -- except
that the flag was in Options.td, so it was silently ignored. I figured
it should be easy to implement, so I did that instead of removing the
flags from Options.td.
I then discovered that link.exe also supports comma-separated lists of
'cd' and 'net', which made the parsing code a bit annoying.
The Alias technique in Options.td is to get nice help output.
Differential Revision: https://reviews.llvm.org/D61067
llvm-svn: 359192
For well-known type IDs, include the name of the type.
To not duplicate the ID->name map, make llvm-readobj call this new
function as well. It has slightly different output, so this also
requires updating a few tests.
Differential Revision: https://reviews.llvm.org/D61086
llvm-svn: 359153
Summary:
We don't take localentry offset into account, and thus may fail to
create a long branch when the gap is just a few bytes smaller than 2^25.
relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431]
relocation R_PPC64_REL24 out of range: 33554436 is not in [-33554432, 33554431]
Fix that by adding the offset to the symbol VA.
Differential Revision: https://reviews.llvm.org/D61058
llvm-svn: 359094
dynamic-section-sh_size.elf was introduced in D25090.
Now it is possible to use yaml2obj instead.
That is what this patch does.
Also I added one more case of a possibly broken .dynamic
section just in case.
llvm-svn: 358990
file-class.a was used to diagnose the "corrupted ELF file: invalid file class"
error when the object was fetched from the archive.
file-class.a contained an object of 16 bytes size. I replaced it with
an echo call (because it is impossible to use yaml2obj for that, and I am
not sure it is worth to support), and also increased its size to 18 bytes.
That allowed to also test a case when such object is a regular input and not an
archive member (we have a bit different logic for these cases).
llvm-svn: 358985
This fixes an issue where a symbol only section at the start of a
PT_LOAD segment, causes incorrect alignment of the file offset for the
start of the segment which results in the output of an invalid ELF.
SHT_PROGBITS was the default output section type in the past.
Differential Revision: https://reviews.llvm.org/D60131
llvm-svn: 358981
The following options: /pdb, /out or /implib now emit in the repro.tar/response.txt only a filename stripped from its path, to avoid non-existent paths on the reproducer's machine.
Differential Revision: https://reviews.llvm.org/D59530
llvm-svn: 358980
Various improvement:
Some offsets in disassembly are incorrect after several layout adjustment. Fix them.
llvm-objdump -D should not be used. -D dumps unrelated non-text sections. Replace them with llvm-objdump -d, llvm-readelf -x, etc
Many llvm-objdump -d tests use {{.*}} . Add the option --no-show-raw-insn to avoid check hex bytes.
ppc64-long-branch.s does not need a shared object. Delete it.
Make ppc64-ifunc.s check 2 ifuncs.
Reviewers: ruiu, espindola
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60998
llvm-svn: 358975
It was initially introduced in D25229 to report the "zero option descriptor size"
error message. In following commits it was broken and did not report this
error anymore. I think that happened because elf object was a result of fuzzing
and it was broken in many ways.
This patch converts this test to a YAML, removes a binary and hence fixes the
original intention.
llvm-svn: 358972
rL358960 "[llvm-mc] - Properly set the the address align field of the compressed sections."
changed the sh_addralign field of the "zlib" compressed debug sections.
llvm-svn: 358961
We can't (currently) meaningfully resolve certain types of relocations
against undefined data symbols. Previously when `--allow-undefined` was
used we were treating such relocation much like weak data symbols and
simply inserting zeros. This change turns such use cases in to an
error.
This means that `--allow-undefined` is no longer effective for data
symbols.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40364
Differential Revision: https://reviews.llvm.org/D60882
llvm-svn: 358899
Summary:
Fixes PR35242. A simplified reproduce:
thread_local int i; int f() { return i; }
% {g++,clang++} -fPIC -shared -ftls-model=local-dynamic -fuse-ld=lld a.cc
ld.lld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol: i in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
In isStaticLinkTimeConstant(), Syn.IsPreemptible is true, so it is not
seen as a constant. The error is then issued in processRelocAux().
A symbol of the local-dynamic TLS model cannot be preempted but it can
preempt symbols of the global-dynamic TLS model in other DSOs.
So it makes some sense that the variable is not static.
This patch fixes the linking error by changing getRelExpr() on
R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} from R_ABS to R_DTPREL.
R_PPC64_DTPREL_* and R_MIPS_TLS_DTPREL_* need similar fixes, but they are not handled in this patch.
As a bonus, we use `if (Expr == R_ABS && !Config->Shared)` to find
ld-to-le opportunities. R_ABS is overloaded here for such STT_TLS symbols.
A dedicated R_DTPREL is clearer.
Differential Revision: https://reviews.llvm.org/D60945
llvm-svn: 358870
Summary:
The DataCount section is necessary for the bulk memory operations
memory.init and data.drop to validate, but it is not recognized by
engines that do not support bulk memory, so emit the section only if
bulk-memory is enabled.
Reviewers: aheejin, dschuff, sbc100
Subscribers: jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60637
llvm-svn: 358798
Another attempt to land the changes in debug line header to prevent duplicate
files in Dwarf 5. I rolled back my previous commit because of a mistake in
generating the object file in a test. Meanwhile, I addressed some offline
comments and changed the implementation; the largest difference is that
MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I
also merged the patch to fix two lld tests that will strt to fail into this
patch.
Original Commit:
https://reviews.llvm.org/D59515
Original Message:
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.
The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)
With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf
5) However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.
llvm-svn: 358732
This is https://bugs.llvm.org//show_bug.cgi?id=39857.
I added the comment with much more details to the bug page,
the short version is below.
The following script and code demonstrates the issue:
aliasto__text = __text;
SECTIONS {
.text 0x1000 : { __text = . ; *(.text) }
}
...
call aliasto__text
LLD fails with "cannot refer to absolute symbol: aliasto__text" error.
It happens because at the moment of scanning the relocations
we do not yet assign the correct/final/any section value for the symbol aliasto__text.
I made a change to Relocations.cpp to fix that.
Also, I had to remove the symbol-location.s test case completely, because now it does not
trigger any error. Since now all linker scripts symbols are resolved to constants, no
errors can be triggered at all it seems. I checked that it is consistent with the behavior
of bfd and gold (they do not trigger errors for the case from symbol-location.s), so it should
be OK. I.e. at least it is probably not the best possible, but natural behavior we obtained.
Differential revision: https://reviews.llvm.org/D55423
llvm-svn: 358652
Summary:
If the output section contains only symbol assignments, we copy flags
from the previous sections. Don't set SHF_ALLOC if NonAlloc is true.
We also have to change the type from SHT_NOBITS to SHT_PROGBITS.
In ld.bfd, bfd_elf_get_default_section_type maps non-alloctable sections to SHT_PROGBITS.
Non-alloctable SHT_NOBITS sections do not make sense.
Fixes PR38626
Differential Revision: https://reviews.llvm.org/D59986
llvm-svn: 358650
This generalizes code and also fixes the broken behavior shown in
one of our test cases for some targets, like x86-64.
The issue occurs when the forward declarations are used in the script.
One of the samples is:
SECTIONS {
foo = ADDR(.text) - ABSOLUTE(ADDR(.text));
};
In that case, we have a broken output when output target does
not use thunks. That happens because thunks creating code
(called from maybeAddThunks)
calls Script->assignAddresses() at least one more time,
what fixups the values. As a result final symbols values can
be different on AArch64 and x86, for example.
In this patch, I generalize and rename maybeAddThunks to
finalizeAddressDependentContent and now it is used and called
by all targets.
Differential revision: https://reviews.llvm.org/D55550
llvm-svn: 358646
Patch by Gabriel Smith.
The address for a section would be evaluated before the region was
switched to. Because of this, the position within the region would not
be updated. After the region is swapped to the dot would be set to the
out of date position within the region, undoing the section address
evaluation.
To fix this, the region is swapped to before the section's address is
evaluated. As part of the fallout of this, expandMemoryRegions needed
to be gated in setDot on the condition that the evaluated address is
less than the dot. This is for the case where sections are not listed
from lowest address to highest address.
Finally, a test for the case where sections are listed "out of order"
was added.
Differential Revision: https://reviews.llvm.org/D60744
llvm-svn: 358638
Patch by Nicholas Allegra.
The Mach-O writer calculates the size of load commands multiple times.
First, Util::assignAddressesToSections() (in MachONormalizedFileFromAtoms.cpp)
calculates the size using headerAndLoadCommandsSize() (in
MachONormalizedFileBinaryWriter.cpp), which creates a temporary
MachOFileLayout for the NormalizedFile, only to retrieve its
headerAndLoadCommandsSize. Later, writeBinary() (in
MachONormalizedFileBinaryWriter.cpp) creates a new layout and uses the offsets
from that layout to actually write out everything in the NormalizedFile.
But the NormalizedFile changes between the first computation and the second.
When Util::assignAddressesToSections is called, file.functionStarts is always
empty because Util::addFunctionStarts has not yet been called. Yet
MachOFileLayout decides whether to include a LC_FUNCTION_STARTS command based
on whether file.functionStarts is nonempty. Therefore, the initial computation
always omits it.
Because padding for the __TEXT segment (to make its size a multiple of the
page size) is added between the load commands and the first section, LLD still
generates a valid binary as long as the amount of padding happens to be large
enough to fit LC_FUNCTION_STARTS command, which it usually is.
However, it's easy to reproduce the issue by adding a section of a precise
size. Given foo.c:
__attribute__((section("__TEXT,__foo")))
char foo[0xd78] = {0};
Run:
clang -dynamiclib -o foo.dylib foo.c -fuse-ld=lld -install_name
/usr/lib/foo.dylib
otool -lvv foo.dylib
This should produce:
truncated or malformed object (offset field of section 1 in LC_SEGMENT_64
command 0 not past the headers of the file)
This commit:
- Changes MachOFileLayout to always assume LC_FUNCTION_STARTS is present for
the initial computation, as long as generating LC_FUNCTION_STARTS is
enabled. It would be slightly better to check whether there are actually
any functions, since no LC_FUNCTION_STARTS will be generated if not, but it
doesn't cause a problem if the initial computation is too high.
- Adds a test.
- Adds an assert in MachOFileLayout::writeSectionContent() that we are not
writing section content into the load commands region (which would happen
if the offset was calculated too low due to the initial load commands size
calculation being too low). Adds an assert in
MachOFileLayout::writeLoadCommands to validate a similar situation where
two size-of-load-commands computations are expected to be equivalent.
llvm-svn: 358545
Summary:
Archives can contain multiple members with the same name. This would
cause ThinLTO links to fail ("Expected at most one ThinLTO module per
bitcode file"). This change implements the same strategy we use in
the ELF linker: make the offset in the archive part of the module
name so that names are unique.
Reviewers: pcc, mehdi_amini, ruiu
Reviewed By: ruiu
Subscribers: eraman, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60549
llvm-svn: 358440
When faced with command line options such as "crtbegin.o appmain.o
-lsomelib crtend.o", GNU ld pulls in all necessary object files from
somelib before proceeding to crtend.o.
LLD operates differently, only loading object files from any
referenced static libraries after processing all input object files.
This uses a similar hack as in the ELF linker. Here, it moves crtend.o
to the end of the vector of object files. This makes sure that
terminator chunks for sections such as .eh_frame gets ordered last,
fixing DWARF exception handling for libgcc and gcc's crtend.o.
Differential Revision: https://reviews.llvm.org/D60628
llvm-svn: 358394
The typo was introduced to llvm MC in rL204769 (fixed in rL358247) and then to lld.
Also, for relocatable-many-sections.s, the size of .symtab changed at some point and the formula needs update.
llvm-svn: 358248
Patch by Robert O'Callahan.
Rust projects tend to link in all object files from all dependent
libraries and rely on --gc-sections to strip unused code and data.
Unfortunately --gc-sections doesn't currently strip any debuginfo
associated with GC'ed sections, so lld links in the full debuginfo from
all dependencies even if almost all that code has been discarded. See
https://github.com/rust-lang/rust/issues/56068 for some details.
Properly stripping debuginfo for discarded sections would be difficult,
but a simple approach that helps significantly is to mark debuginfo
sections as live only if their associated object file has at least one
live code/data section. This patch does that. In a (contrived but not
totally artificial) Rust testcase linked above, it reduces the final
binary size from 46MB to 5.1MB.
Differential Revision: https://reviews.llvm.org/D54747
llvm-svn: 358069
Previously the tests in lld for RISC-V were given in yaml format as
LLVM's RISC-V assembler support was incomplete. Now that the
assembler/disassembler has matured we can rewrite all tests to use
LLVM's tools.
Differential Revision: https://reviews.llvm.org/D60415
llvm-svn: 357996
For partitions I intend to use the same set of version indexes in
each partition for simplicity. Since each partition will need its own
VersionNeedSection this will require moving the verneed tracking out of
VersionNeedSection. The way I've done this is to move most of the tracking
into SharedFile. What will eventually become the per-partition tracking
still lives in VersionNeedSection.
As a bonus the code gets a little simpler and more consistent with how we
handle verdef.
Differential Revision: https://reviews.llvm.org/D60307
llvm-svn: 357926
Previously, we drop symbols starting with .L from the symbol table, so
if there is a relocation that refers a .L symbol, it ended up
referencing a null -- which happened to be interpreted as an absolute
symbol.
This patch copies all symbols including local ones if -emit-reloc is
given.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41385
Differential Revision: https://reviews.llvm.org/D60306
llvm-svn: 357885
This should have been part of rL357710 but was overlooked because
in our test code the function in question was also used in other
relocations that caused it to be added to the table anyway.
Differential Revision: https://reviews.llvm.org/D60296
llvm-svn: 357737
Summary:
Take the Index into account in `getDelayImportTable`, otherwise we
always return the entry for the first delay DLL reference.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60081
llvm-svn: 357697
See https://reviews.llvm.org/D59860
The initial version of this change effected more than just the
error message. This version is scoped down to only effect the error
itself.
llvm-svn: 357328
Summary:
Makes it a linker error if the "atomics" feature is used but the user
does not opt in to shared memory or if "atomics" is disallowed but the
user does opt in to shared memory. Also check that an appropriate max
memory size is supplied if shared memory is used.
Reviewers: sbc100, aheejin
Subscribers: dschuff, jgravelle-google, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59281
llvm-svn: 357310
Generate import modules for each imported DLL, along with its symbol stream.
Also create COFF groups in the * Linker * module, one for each PartialSection (input, unmerged sections)
Currently COFF groups are disabled for MINGW because it significantly increases PDB sizes. We could enable that later with an option.
The overall objective for this change is to support code hot patching tools. Such tools need to know the import libraries used, from the PDB alone.
Differential Revision: https://reviews.llvm.org/D54802
llvm-svn: 357308
Recommit r356666 with fixes for buildbot failure, as well as handling for
--emit-relocs, which we decide not to emit any relocation sections as the
table is already position independent and an offline tool can deduce the
relocations.
Instead of creating extra Synthetic .ARM.exidx sections to account for
gaps in the table, create a single .ARM.exidx SyntheticSection that can
derive the contents of the gaps from a sorted list of the executable
InputSections. This has the benefit of moving the ARM specific code for
SyntheticSections in SHF_LINK_ORDER processing and the table merging code
into the ARM specific SyntheticSection. This also makes it easier to create
EXIDX_CANTUNWIND table entries for executable InputSections that don't
have an associated .ARM.exidx section.
Fixes pr40277
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 357160
Patch by Tiancong Wang.
In D36351, Call-Chain Clustering (C3) heuristic is implemented with
option --call-graph-ordering-file <file>.
This patch adds a flag --print-symbol-order=<file> to LLD, and when
specified, it prints out the symbols ordered by the heuristics to the
file. The symbols printout is helpful to those who want to understand
the heuristics and want to reproduce the ordering with
--symbol-ordering-file in later pass.
Differential Revision: https://reviews.llvm.org/D59311
llvm-svn: 357133
No longer require workarounds for output to "-" (stdout) for
Windows. These workarounds were just hiding the actual problem which has
been fixed in r357058.
Differential Revision: https://reviews.llvm.org/D59824
llvm-svn: 357072
This reverts commit rL357020
Reason: rL357018, which this commit depend on breaks the test:
llvm/test/tools/llvm-objdump/embedded-source.test on some architectures.
llvm-svn: 357025
This change implements lowering of references global symbols in PIC
mode.
This change implements lowering of global references in PIC mode using a
new @GOT reference type. @GOT references can be used with function or
data symbol names combined with the get_global instruction. In this case
the linker will insert the wasm global that stores the address of the
symbol (either in memory for data symbols or in the wasm table for
function symbols).
For now I'm continuing to use the R_WASM_GLOBAL_INDEX_LEB relocation
type for this type of reference which means that this relocation type
can refer to either a global or a function or data symbol. We could
choose to introduce specific relocation types for GOT entries in the
future. See the current dynamic linking proposal:
https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md
Differential Revision: https://reviews.llvm.org/D54647
llvm-svn: 357022
Reapply rL356943; the previous attempt was reverted because the patch rL356941
that this depended on had broken a test.
Original commit message:
[lld] Prevent duplicate files in debug line header in dwarf 5.
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59671
llvm-svn: 357020
Do not pipe binary data between processes in lit tests this time,
since it turns out that can break on Windows.
This reverts commit 84c8652fc3.
llvm-svn: 356975
Summary:
This should address remaining issues discussed in PR36555.
Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to
express relocations types relative to the GOT base. We have
_GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) !=
start(.got.plt)
This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g.
glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt),
which is not true.
extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;
return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32
In this patch, we
* Change all GOT*_FROM_END to GOTPLT* to fix the problem.
* Add HasGotPltOffRel to denote whether .got.plt should be kept even if
the section is empty.
* Simplify GotSection::empty and GotPltSection::empty by setting
HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early.
The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't
have to compute the offset start(.got.plt) - Ebx (it is constant 0).
We still diverge from ld.bfd (at least in most cases) and gold in that
.got.plt and .got are not adjacent, but the advantage doing that is
unclear.
Reviewers: ruiu, sivachandra, espindola
Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59594
llvm-svn: 356968
Summary:
Changes to a couple of tests that will start failing after https://reviews.llvm.org/D59515 is submitted.
Reviewers: echristo, ruiu, espindola
Reviewed By: echristo, ruiu
Subscribers: emaste, arichardson, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59671
llvm-svn: 356943
Take module DBI creation out of PDBLinker::addObjFile() into its own function.
This is groundwork towards parallelizable type merging, as proposed in D59226.
Differential Revision: https://reviews.llvm.org/D59261
llvm-svn: 356815
Summary:
Adds --check-features and --no-check-features. The default for now is
to enable the checking, but this might change in the future.
Also adds --features=foo,bar for precisely controlling the features
used in the output binary.
Depends on D59173.
Reviewers: sbc100, aheejin
Subscribers: dschuff, jgravelle-google, sunfish, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59274
llvm-svn: 356805
There is a reproducible buildbot failure (segfault) on the 2 stage
clang-cmake-armv8-lld bot. Reverting while I investigate.
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 356684
Instead of creating extra Synthetic .ARM.exidx sections to account for
gaps in the table, create a single .ARM.exidx SyntheticSection that can
derive the contents of the gaps from a sorted list of the executable
InputSections. This has the benefit of moving the ARM specific code for
SyntheticSections in SHF_LINK_ORDER processing and the table merging code
into the ARM specific SyntheticSection. This also makes it easier to create
EXIDX_CANTUNWIND table entries for executable InputSections that don't
have an associated .ARM.exidx section.
Fixes pr40277
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 356666
Summary:
Implements a new target features section in assembly and object files
that records what features are used, required, and disallowed in
WebAssembly objects. The linker uses this information to ensure that
all objects participating in a link are feature-compatible and records
the set of used features in the output binary for use by optimizers
and other tools later in the toolchain.
The "atomics" feature is always required or disallowed to prevent
linking code with stripped atomics into multithreaded binaries. Other
features are marked used if they are enabled globally or on any
function in a module.
Future CLs will add linker flags for ignoring feature compatibility
checks and for specifying the set of allowed features, implement using
the presence of the "atomics" feature to control the type of memory
and segments in the linked binary, and add front-end flags for
relaxing the linkage policy for atomics.
Reviewers: aheejin, sbc100, dschuff
Subscribers: jgravelle-google, hiraditya, sunfish, mgrang, jfb, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59173
llvm-svn: 356610
D58391 changed the LTO pipelines to add the tailcall elimination pass.
This caused three LLD tests to fail.
Differential Revision: https://reviews.llvm.org/D59604
llvm-svn: 356593
Summary:
This implements Rui Ueyama's idea in PR39044.
I've checked that ld.bfd and gold do not have the power-of-2 requirement
and do not require sh_entsize to be a multiple of sh_align.
Now on the updated test merge-entsize.s, all the 3 linkers happily
create .rodata that is not 3-byte aligned.
This has a use case in Linux arch/x86/crypto/sha512-avx2-asm.S
It uses sh_entsize of 640, which is not a power of 2.
See https://github.com/ClangBuiltLinux/linux/issues/417
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: nickdesaulniers, E5ten, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59478
llvm-svn: 356428
Before, empty debug streams were written as 8 bytes (4 bytes signature + 4 bytes for the GlobalRefs count).
With this patch, unused empty streams aren't emitted anymore. Modules now encode 65535 as an 'unused stream' value, by convention.
Also fix the * Linker * contrib section which wasn't correctly emitted previously.
Differential Revision: https://reviews.llvm.org/D59502
llvm-svn: 356395
It seems to pass fine on my Mac, and it running it only on Windows made
me miss it in r355959 and required r355959.
When the test was added in r288992 we still used Win-only
UnDecorateSymbolName() for demangling. Now we use LLVM's
microsoftDemangle() which is cross-platform.
Differential Revision: https://reviews.llvm.org/D59497
llvm-svn: 356380
For these types of relocations an absolute memory address is
required which is not possible for undefined data symbols. For symbols
that can be undefined at link time (i.e. external data symbols in
shared libraries) a different type of relocation (i.e. via a GOT) will
be needed.
Differential Revision: https://reviews.llvm.org/D59337
llvm-svn: 356310
arm-plt-reloc.s arm-thumb-plt-reloc.s: update offset calculations
pack-dyn-relocs-loop.s: this test is very sensitive to exact section
offsets and sizes. If we comment out the following two lines in
SyntheticSections.cpp, we should reproduce `ld.lld: error: thunk
creation not converged` caused by oscillation of the section size.
if (RelocData.size() < OldSize)
RelocData.append(OldSize - RelocData.size(), 0);
Use -z norelro to counteract the layout change (to be more specific,
we have to place .dynamic below .foo so that offset(foo) remains 0x10004)
llvm-svn: 356229
Summary:
Based on Peter Collingbourne's suggestion in D56828.
Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .bss)
Old: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data .bss)
New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) PT_LOAD(.data. .bss)
The new layout reflects the runtime memory mappings.
By having two PT_LOAD segments, we can utilize the NOBITS part of the
first PT_LOAD and save bytes for .bss.rel.ro.
.bss.rel.ro is currently small and only used by copy relocations of
symbols in read-only segments, but it can be used for other purposes in
the future, e.g. if a relro section's statically relocated data is all
zeros, we can move it to .bss.rel.ro.
Reviewers: espindola, ruiu, pcc
Reviewed By: ruiu
Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58892
llvm-svn: 356226
/summary prints information about the data (OBJ/LIB/PDB) processed by LLD. The goal is have an estimate about the inputs and outputs, to better understand where the timings go.
Differential Revision: https://reviews.llvm.org/D58599
llvm-svn: 356188
We allow an archive file without symbol table as a linker input as a
workaround for a very common error in LTO build. But that logic worked
even for an archive file containing non-bitcode files, which is not
expected. This patch limits that workaround to one that contains only
bitcode files.
Differential Revision: https://reviews.llvm.org/D59373
llvm-svn: 356186
Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss)
New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss)
The placement of | indicates page alignment caused by PT_GNU_RELRO. The
new layout has simpler rules and saves space for many cases.
Old size: roundup(.data) + roundup(.data.rel.ro)
New size: roundup(.data.rel.ro + .bss.rel.ro) + .data
Other advantages:
* At runtime the 3 memory mappings decrease to 2.
* start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This
simplifies binary manipulation tools.
GNU strip before 2.31 discards PT_GNU_RELRO if its
address is not equal to the start of its associated PT_LOAD.
This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f
But with this change, we will be compatible with GNU strip before 2.31
* Before, .got.plt (non-relro by default) was placed before .got (relro
by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_
(start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END)
(https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we
can improve on this regard if we'd like to.
Reviewers: ruiu, espindola, pcc
Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert
Differential Revision: https://reviews.llvm.org/D56828
llvm-svn: 356117
When linking shared libraries, we import a mutable wasm global
to represent the address of each undefined data symbol.
This is a step towards supporting dynamic linking and shared
libraries.
Differential Revision: https://reviews.llvm.org/D59270
llvm-svn: 355988
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
Original llvm-svn: 355964
llvm-svn: 355984
This does not appear to be necessary because StringTableSection does not
need to be finalized, which also means that we can remove the call to
finalizeSynthetic on .dynstr.
Differential Revision: https://reviews.llvm.org/D59240
llvm-svn: 355977
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
llvm-svn: 355964
On Darwin targets, llvm-ar creates a Darwin format archive by default,
which ld.lld can't read, so it was printing an unexpected error.
llvm-svn: 355894
This makes lld-link's output a bit more concise. Since most developers can't
read mangled names, this should make the output a bit easier to understand as
well. It also makes lld-link's output consistent with ld.lld's output.
(link.exe prints both demangled and mangled names; lld-link used to match
link.exe output but now no longer does.)
For people working on toolchains, add a `/demangle:no` flag that makes lld-link
print the mangled name instead of the demangled name. (If desired, people could
pipe that through `demumble -b` to get the old behavior of both demangled and
mangled output.)
Differential Revision: https://reviews.llvm.org/D58132
llvm-svn: 355878
This unit test fails if 'zed' appears in your build path, as lld is
echoing out the path of the source file. Change the unit test to
explicitly only match everything after the 'Symbols [' line of the
output, to make sure that this test doesn't inadvertently fail due to
the build path.
llvm-svn: 355748
When mismatched #pragma detect_mismatch declarations occur, now print the conflicting OBJs.
lld-link: error: /failifmismatch: mismatch detected for 'TEST':
>>> test.obj has value 1
>>> test2.obj has value 2
Fixes PR38579
Differential Revision: https://reviews.llvm.org/D58910
llvm-svn: 355543
Summary:
We disabled MachineBlockPlacement pass in D58953, and this test result
changes as the result of it.
Reviewers: kripken
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58954
llvm-svn: 355438
If the permission does not permit writing and the standard input is a
terminal, rm gives an annoying prompt. chmod u+w to make the output
directory easier to delete.
llvm-svn: 355382
This lets us detect file size overflows when creating a 64-bit binary on
a 32-bit machine.
Differential Revision: https://reviews.llvm.org/D58840
llvm-svn: 355218
This lets us remove the special case from Writer::writeSections(), and also
fixes a bug where .eh_frame_hdr isn't necessarily written in the correct
order if a linker script moves .eh_frame and .eh_frame_hdr into the same
output section.
Differential Revision: https://reviews.llvm.org/D58795
llvm-svn: 355153
Summary:
In the clang UI, replaces -mthread-model posix with -matomics as the
source of truth on threading. In the backend, replaces
-thread-model=posix with the atomics target feature, which is now
collected on the WebAssemblyTargetMachine along with all other used
features. These collected features will also be used to emit the
target features section in the future.
The default configuration for the backend is thread-model=posix and no
atomics, which was previously an invalid configuration. This change
makes the default valid because the thread model is ignored.
A side effect of this change is that objects are never emitted with
passive segments. It will instead be up to the linker to decide
whether sections should be active or passive based on whether atomics
are used in the final link.
Reviewers: aheejin, sbc100, dschuff
Subscribers: mehdi_amini, jgravelle-google, hiraditya, sunfish, steven_wu, dexonsmith, rupprecht, jfb, jdoerfert, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D58742
llvm-svn: 355112
This patch removes the precompiled binary from inputs,
replacing it with a YAML. And teaches LLD to report a
section name in case of such error.
Differential revision: https://reviews.llvm.org/D58670
llvm-svn: 354959
Summary:
The gold linker allowed you to output the ELF files after LTO was run. It did
it by using the 'obj-path' option. This replicates that behavior.
Reviewers: espindola, ruiu, MaskRay, pcc
Reviewed By: MaskRay, pcc
Subscribers: grimar, emaste, inglorion, arichardson, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D56046
llvm-svn: 354917
The linux kernel uses an old flag -p/-no-pipeline-knowledge that is
accepted by bfd and gold but ignored by modern versions of them. The
original option is very old and is pre-ABI, it sometimes comes up in
code-bases that had support for pre ABI toolchains. The Linux kernel uses
it in 3 places in the ARM specific section.
Differential Revision: https://reviews.llvm.org/D58540
llvm-svn: 354769
yaml2obj used to require the Symbol field in relocations, but it hasn't
done so for a couple of years. Another change to yaml2obj will soon land
that will look up the symbol by name or index, if present, and emit an
error if not found. This will mean that an explicit symbol reference
(even to an empty-named symbol) that does not reference a symbol
declared in the yaml will result in an error.
This patch updates tests that would otherwise start emitting errors.
Reviewed by: ruiu, grimar
Differential Revision: https://reviews.llvm.org/D58508
llvm-svn: 354666
Previously we could emit a warning and generate a potentially invalid
wasm module (due to call sites and functions having conflicting
signatures). Now, rather than create invalid binaries we handle such
cases by creating stub functions containing unreachable, effectively
turning these into runtime errors rather than validation failures.
Differential Revision: https://reviews.llvm.org/D57909
llvm-svn: 354528
Three MIPS-specific sections `.reginfo`, `.MIPS.options`, and `.MIPS.abiflags`
are used by loader to read their contents and setup environment for running
a program. Loader looks up these data in the corresponding segments:
`PT_MIPS_REGINFO`, `PT_MIPS_OPTIONS`, and `PT_MIPS_ABIFLAGS` respectively.
This patch put these sections to separate segments like we do already
for ARM `SHT_ARM_EXIDX` section.
Differential Revision: http://reviews.llvm.org/D58381
llvm-svn: 354468
Summary:
We translate @llvm.used to COFF by generating /include directives
in the .drectve section. However, in LTO links, this happens after
directives have already been processed, so the new directives do
not take effect. This change marks @llvm.used symbols as GCRoots
so that they are preserved as intended.
Fixes PR40733.
Reviewers: rnk, pcc, ruiu
Reviewed By: ruiu
Subscribers: mehdi_amini, steven_wu, dexonsmith, dang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58255
llvm-svn: 354410
Summary:
Rename MemoryIndex to InitFlags and implement logic for determining
data segment layout in ObjectYAML and MC. Also adds a "passive" flag
for the .section assembler directive although this cannot be assembled
yet because the assembler does not support data sections.
Reviewers: sbc100, aardappel, aheejin, dschuff
Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57938
llvm-svn: 354397
This is a private undocumented option, intended to be used by
the MinGW driver frontend.
Also restructure the condition to put if (Config->MinGW) first.
This changes the behaviour for the tautological combination of
-export-all-symbols without -lldmingw.
Differential Revision: https://reviews.llvm.org/D58380
llvm-svn: 354386
MIPS R6 code uses the `R_MIPS_PC26_S2` relocation for calls which might
cross boundaries of non-PIC-to-PIC code. We need to create a LA25 thunks
for that case.
llvm-svn: 354312
The patch solves two tasks:
1. MIPS ABI allows to mix regular and microMIPS code and perform
cross-mode jumps. Linker needs to detect such cases and replace
jump/branch instructions by their cross-mode equivalents.
2. Other tools like dunamic linkers need to recognize cases when dynamic
table entries, e_entry field of an ELF header etc point to microMIPS
symbol. Linker should provide such information.
The first task is implemented in the `MIPS<ELFT>::relocateOne()` method.
New routine `fixupCrossModeJump` detects ISA mode change, checks and
replaces an instruction.
The main problem is how to recognize that relocation target is microMIPS
symbol. For absolute and section symbols compiler or assembler set the
less-significant bit of the symbol's value or sum of the symbol's value
and addend. And this bit signals to linker about microMIPS code. For
global symbols compiler cannot do the same trick because other tools like,
for example, disassembler wants to know an actual position of the symbol.
So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field.
In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and
cannot access any symbol's attributes. To pass type of the symbol
(regular/microMIPS) to that routine as well as other places where we
write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field
etc) we set when necessary a less-significant bit in the `getSymVA`
function.
Differential revision: https://reviews.llvm.org/D40147
llvm-svn: 354311
On PowerPC64, it is necessary to keep the LocalEntry bits in st_other,
especially when -r is used. Otherwise, when the resulting object is used
in a posterior linking, LocalEntry info will be unavailable and
functions may be called through the wrong entrypoint.
Patch by Leandro Lupori.
Differential Revision: https://reviews.llvm.org/D56782
llvm-svn: 354184
Previously, we showed the following message for an unknown relocation:
foo.o: unrecognized reloc 256
This patch improves it so that the error message includes a symbol name:
foo.o: unknown relocation (256) against symbol bar
llvm-svn: 354040
Turns out nobody understands what "conflicting comdat type" is supposed to
mean, so just emit a regular "duplicate symbol" error and move the comdat
selection information into /verbose output.
This also fixes a problem where the error output would depend on the order of
.obj files passed. Before this patch:
- If passed `one_only.obj discard.obj`, lld-link would only err "conflicting
comdat type"
- If passed `discard.obj one_only.obj`, lld-link would err "conflicting comdat
type" and then "duplicate symbol"
Now lld-link only errs "duplicate symbol" in both cases.
I considered adding a "Detail" parameter to reportDuplicate() that's printed in
parens at the end of the "duplicate symbol" diag if present, and then put the
comdat selection mismatch details there, but since users don't know what it's
supposed to mean decided against it. I also considered special-casing the
Detail message for one_only/discard mismatches, which in practice means
"function defined as inline in TU 1 but as out-of-line in TU 2", but I wasn't
sure how useful it is so I omitted that too.
Differential Revision: https://reviews.llvm.org/D58180
llvm-svn: 354006
Non-GOT non-PLT relocations to non-preemptible ifuncs result in the
creation of a canonical PLT, which now takes the identity of the IFUNC
in the symbol table. This (a) ensures address consistency inside and
outside the module, and (b) fixes a bug where some of these relocations
end up pointing to the resolver.
Fixes (at least) PR40474 and PR40501.
Differential Revision: https://reviews.llvm.org/D57371
llvm-svn: 353981
This fixes a 7.0 -> 8.0 regression when parsing
OUTPUT_FORMAT("elf32-powerpc"); or elf32-bigmips directive in ldscripts
as well as an unknown emulation error when lld is invoked by clang due
to missed elf32ppclinux case.
Patch by vit9696
Differential Revision: https://reviews.llvm.org/D58005
llvm-svn: 353968
Previously, we validated -z options after we process --version or --help flags.
So, if one of these flags is given, we wouldn't show an "unknown -z option"
error. This patch fixes that behavior.
Differential Revision: https://reviews.llvm.org/D55446
llvm-svn: 353967
The printing of branch operands for call instructions was changed to properly
handle negative offsets. Updating the tests to reflect that.
llvm-svn: 353866
gold accepts quoted strings. binutils requires quoted strings for some
kinds of symbols, e.g.:
it accepts quoted symbols with @ in name:
$ echo 'EXTERN("__libc_start_main@@GLIBC_2.2.5")' > a.script
$ g++ a.script
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
but rejects them if unquoted:
$ echo 'EXTERN(__libc_start_main@@GLIBC_2.2.5)' > a.script
$ g++ a.script
a.script: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
To maintain compatibility with existing linker scripts support quoted
strings in lld as well.
Patch by Lucian Adrian Grijincu.
Differential Revision: https://reviews.llvm.org/D57987
llvm-svn: 353756
The code producing error messages relating to missing thin archive
members was missing any testing as far as I could see, so this patch
adds a test for it.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D57899
llvm-svn: 353508
Add a flag to allow symbols to have a wasm import name which differs from the
linker symbol name, allowing the linker to link code using the import_module
attribute.
Differential Revision: https://reviews.llvm.org/D57632
llvm-svn: 353473
R_X86_64_PC{8,16} relocations are sign-extended, so when we check
for relocation overflow, we had to use checkInt instead of checkUInt.
I confirmed that GNU linkers create the same output for the test case.
llvm-svn: 353437
This is the same as D57749, but for x64 target.
"ELF Handling For Thread-Local Storage" p41 says (https://www.akkadia.org/drepper/tls.pdf):
R_X86_64_GOTTPOFF relocation is used for IE TLS models.
Hence if linker sees this relocation we should add DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57821
llvm-svn: 353378
With the following changes:
1) Compilation fix:
std::atomic<bool> HasStaticTlsModel = false; ->
std::atomic<bool> HasStaticTlsModel{false};
2) Adjusted the comment in code.
Initial commit message:
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
----
Modified : /lld/trunk/ELF/Arch/X86.cpp
Modified : /lld/trunk/ELF/Config.h
Modified : /lld/trunk/ELF/SyntheticSections.cpp
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model1.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model2.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model3.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model4.s
Added : /lld/trunk/test/ELF/i386-static-tls-model.s
Modified : /lld/trunk/test/ELF/i386-tls-ie-shared.s
Modified : /lld/trunk/test/ELF/tls-dynamic-i686.s
Modified : /lld/trunk/test/ELF/tls-opt-iele-i686-nopic.s
llvm-svn: 353299
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
llvm-svn: 353293
When a thunk is created to a PLT entry, the call to the thunk is converted
to a non-plt expression with fromPlt(). If the thunk becomes unusable we
retarget the relocation back to its original target and try again. When we
do this we need to make sure that we restore the PLT form of the expression
with toPlt().
This change adds a test case that will fail if toPlt() is removed. We need
to have a call to a preemptible symbol defined within the link unit. If
toPlt() is removed then the relocation to the thunk to the PLT entry for the
preemptible symbol will be retargeted to the preemptible symbol itself
instead of its PLT entry.
Differential Revision: https://reviews.llvm.org/D57743
llvm-svn: 353285
Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.
R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr
Reviewers: ruiu, sfertile, syzaara, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57673
llvm-svn: 353262
Fangrui Song