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
Sam Clegg