merge upstream #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367200 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, when `--vs-diagnostics` was used, the linker printed something like hidden(undef.s): error: undefined hidden symbol: foo >>> referenced by undef.s:15 Differential Revision: https://reviews.llvm.org/D65499 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367515 91177308-0d34-0410-b5e6-96231b3b80d8
* Add --no-show-raw-insn to llvm-objdump -d tests * When linking an executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if %t.so doesn't have DT_SONAME. .dynstr will have varying lengths on different systems. Add -soname so that the string in .dynstr is of fixed length to make tests more robust. * Rename i386-tls-initial-exec-local.s to i386-tls-ie-local.s * Refactor tls-initial-exec-local.s to x86-64-tls-ie-local.s git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367533 91177308-0d34-0410-b5e6-96231b3b80d8
…on of a duplicate symbol. We extract and print the source location in the message header so that Visual Studio is able to parse it and jump there. As duplicate symbols are defined in several locations, it is more convenient to have separate error messages, which allows a user to easily access all the locations. Differential Revision: https://reviews.llvm.org/D65213 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367536 91177308-0d34-0410-b5e6-96231b3b80d8
… with traps only if -z separate-code is specified This patch 1) adds -z separate-code and -z noseparate-code (default). 2) changes the condition that the last page of last PF_X PT_LOAD is padded with trap instructions. Current condition (after D33630): if there is no `SECTIONS` commands. After this change: if -z separate-code is specified. -z separate-code was introduced to ld.bfd in 2018, to place the text segment in its own pages. There is no overlap in pages between an executable segment and a non-executable segment: 1) RX cannot load initial contents from R or RW(or non-SHF_ALLOC). 2) R and RW(or non-SHF_ALLOC) cannot load initial contents from RX. lld's current status: - Between R and RX: in `Writer<ELFT>::fixSectionAlignments()`, the start of a segment is always aligned to maxPageSize, so the initial contents loaded by R and RX do not overlap. I plan to allow overlaps in D64906 if -z noseparate-code is in effect. - Between RX and RW(or non-SHF_ALLOC if RW doesn't exist): we currently unconditionally pad the last page to commonPageSize (defaults to 4096 on all targets we support). This patch will make it effective only if -z separate-code is specified. -z separate-code is a dubious feature that intends to reduce the number of ROP gadgets (which is actually ineffective because attackers can find plenty of gadgets in the text segment, no need to find gadgets in non-code regions). With the overlapping PT_LOAD technique D64906, -z noseparate-code removes two more alignments at segment boundaries than -z separate-code. This saves at most defaultCommonPageSize*2 bytes, which are significant on targets with large defaultCommonPageSize (AArch64/MIPS/PPC: 65536). Issues/feedback on alignment at segment boundaries to help understand the implication: * binutils PR24490 (the situation on ld.bfd is worse because they have two R-- on both sides of R-E so more alignments.) * In binutils, the 2018-02-27 commit "ld: Add --enable-separate-code" made -z separate-code the default on Linux. richfelker/musl-cross-make@d969dea In musl-cross-make, binutils is configured with --disable-separate-code to address size regressions caused by -z separate-code. (lld actually has the same issue, which I plan to fix in a future patch. The ld.bfd x86 status is worse because they default to max-page-size=0x200000). * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237676 people want smaller code size. This patch will remove one alignment boundary. * Stef O'Rear: I'm opposed to any kind of page alignment at the text/rodata line (having a partial page of text aliased as rodata and vice versa has no demonstrable harm, and I actually care about small systems). So, make -z noseparate-code the default. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64903 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367537 91177308-0d34-0410-b5e6-96231b3b80d8
The Archive object created when loading an archive specified with wholearchive got cleaned up immediately, when the owning std::unique_ptr went out of scope, even if persisted StringRefs pointed to memory that belonged to the archive, which no longer was mapped in memory. This hasn't been an issue with regular (as opposed to thin) archives, as references to the member objects has kept the mapping for the whole archive file alive - but with thin archives, all such references point to other files. Add the std::unique_ptr to the arena allocator, to retain it as long as necessary. This fixes (the last issue raised in) PR42388. Differential Revision: https://reviews.llvm.org/D65565 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367599 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367643 91177308-0d34-0410-b5e6-96231b3b80d8
1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367649 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367650 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367651 91177308-0d34-0410-b5e6-96231b3b80d8
…ing operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367658 91177308-0d34-0410-b5e6-96231b3b80d8
…as exists This avoids a spurious and confusing log message in cases where both e.g. "alias" and "__imp_alias" exist. Differential Revision: https://reviews.llvm.org/D65598 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367673 91177308-0d34-0410-b5e6-96231b3b80d8
It's the __delayLoadHelper2 function that overwrites the jump table slot, not this thunk. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367674 91177308-0d34-0410-b5e6-96231b3b80d8
…k-dyn-relocs=android[+relr]
An R_*_IRELATIVE represents the address of a STT_GNU_IFUNC symbol
(redirected at runtime) which is non-preemptable and is not associated
with a canonical PLT (associated with a symbol with a section index of
SHN_UNDEF but a non-zero st_value).
.rel[a].plt [DT_JMPREL, DT_JMPREL+DT_JMPRELSZ) contains relocations that
can be lazily resolved. R_*_IRELATIVE are always eagerly resolved, so
conceptually they do not belong to .rela.plt. "iplt" is mostly a misnomer.
glibc powerpc and powerpc64 do not resolve R_*_IRELATIVE if they are in .rela.plt.
// a.o - synthesized PLT call stub has an R_*_IRELATIVE
void ifunc(); int main() { ifunc(); }
// b.o
static void real() {}
asm (".type ifunc, %gnu_indirect_function");
void *ifunc() { return ℜ }
The lld-linked executable crashes. ld.bfd places R_*_IRELATIVE in
.rela.dyn and the executable works.
glibc i386, x86_64, and aarch64 have logic
(glibc/sysdeps/*/dl-machine.h:elf_machine_lazy_rel) to eagerly resolve
R_*_IRELATIVE in .rel[a].plt so the lld-linked executable works.
Move R_*_IRELATIVE from .rel[a].plt to .rel[a].dyn to fix the crashes on
glibc powerpc/powerpc64. This also helps simplifying ifunc
implementation in FreeBSD rtld-elf powerpc64.
If --pack-dyn-relocs=android[+relr] is specified, the Android packed
dynamic relocation format is used for .rela.dyn. We cannot name
in.relaIplt ".rela.dyn" because the output section will have mixed
formats. This can be improved in the future.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D65651
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367745 91177308-0d34-0410-b5e6-96231b3b80d8
Delete version-script-missing.s: it is covered by version-script-noundef.s
Delete version-script-anonymous-local.s: it is covered by version-script-{glob,weak}.s etc
Delete version-script-no-warn{,2}.s: add --fatal-warnings to some version-script.s commands instead
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367778 91177308-0d34-0410-b5e6-96231b3b80d8
F_{None,Text,Append} are kept for compatibility since r334221.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367800 91177308-0d34-0410-b5e6-96231b3b80d8
These symbols actually point to the symbol's IAT entry, which obviously is different from the symbol itself (which is imported from a different module and doesn't exist in the current one). Omitting this symbol helps gdb inspect automatically imported symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574 for discussion on the matter. Surprisingly, those extra symbols don't seem to be an issue for gdb when the sources have been built with clang, only with gcc. The actual logic in gdb that this depends on still is unknown, but omitting these symbols from the symbol table is the right thing to do in any case. Differential Revision: https://reviews.llvm.org/D65727 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367836 91177308-0d34-0410-b5e6-96231b3b80d8
…ries With GNU tools, delayload is handled completely differently. (One creates a specific delayload import library using dlltool and then links against it instead of the normal import library.) Instead of requiring using -Xlink=-delayload:lib.dll, we can provide an lld specific option for this. Differential Revision: https://reviews.llvm.org/D65728 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367837 91177308-0d34-0410-b5e6-96231b3b80d8
… info assembly format for better readability git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367850 91177308-0d34-0410-b5e6-96231b3b80d8
…ew debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367861 91177308-0d34-0410-b5e6-96231b3b80d8
… info assembly format for better readability git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367867 91177308-0d34-0410-b5e6-96231b3b80d8
…ripts
We prioritize non-* wildcards overs VER_NDX_LOCAL/VER_NDX_GLOBAL "*".
This patch generalizes the rule to "*" of other versions and thus fixes PR40176.
I don't feel strongly about this GNU linkers' behavior but the
generalization simplifies code.
Delete `config->defaultSymbolVersion` which was used to special case
VER_NDX_LOCAL/VER_NDX_GLOBAL "*".
In `SymbolTable::scanVersionScript`, custom versions are handled the same
way as VER_NDX_LOCAL/VER_NDX_GLOBAL. So merge
`config->versionScript{Locals,Globals}` into `config->versionDefinitions`.
Overall this seems to simplify the code.
In `SymbolTable::assign{Exact,Wildcard}Versions`,
`sym->verdefIndex == config->defaultSymbolVersion` is changed to
`verdefIndex == UINT32_C(-1)`.
This allows us to give duplicate assignment diagnostics for
`{ global: foo; };` `V1 { global: foo; };`
In test/linkerscript/version-script.s:
vs_index of an undefined symbol changes from 0 to 1. This doesn't matter (arguably 1 is better because the binding is STB_GLOBAL) because vs_index of an undefined symbol is ignored.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D65716
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367869 91177308-0d34-0410-b5e6-96231b3b80d8
Some tls-*.s tests do not test generic TLS behavior but rather are x86 specific. Rename them to i386-*.s or x86-64-*.s Delete tls-static.s: covered by tls-opt.s Delete tls-opt-no-plt.s: add --implicit-check-not=.plt to x86-64-tls-gdie.s to cover it Rename tls-dynamic-i686.s to i386-tls-dynamic.s Rename tls-i686.s to i386-tls-le.s Rename tls-opt-i686.s to i386-tls-opt.s Rename tls-opt-iele-i686-nopic.s to i386-tls-opt-iele-nopic.s Rename tls-dynamic.s to x86-64-tls-dynamic.s . IE should be split off in the future. Rename tls-error.s to x86-64-reloc-tpoff32-error.s Rename tls-opt-gdie.s to x86-64-tls-gdie.s Rename tls-opt-x86_64-noplt.s to x86-64-tls-opt-noplt.s Rename tls-opt-local.s => x86-64-tls-ie-opt-local.s . It can be merged with x86-64-tls-ie-local.s in the future. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@367877 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D65639 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368032 91177308-0d34-0410-b5e6-96231b3b80d8
…and SharedSymbol This is a case missed by D64136. If %t1.o has a weak reference on foo, and %t2.so has a non-weak reference on foo: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # undefined symbol: foo; STB_GLOBAL 2. gold %t1.o %t2.so # ok; STB_WEAK 3. gold %t2.so %t1.o # undefined reference to 'foo'; STB_GLOBAL 4. ld.bfd %t1.o %t2.so # undefined reference to `foo'; STB_WEAK 5. ld.bfd %t2.so %t1.o # undefined reference to `foo'; STB_WEAK ``` It can be argued that in both cases, the binding of the undefined foo should be set to STB_WEAK, because the binding should not be affected by referenced from shared objects. --allow-shlib-undefined doesn't suppress errors (3,4,5), but -shared or --noinhibit-exec allows ld.bfd/gold to produce a binary: ``` 3. gold -shared %t2.so %t1.o # ok; STB_GLOBAL 4. ld.bfd -shared %t2.so %t1.o # ok; STB_WEAK 5. ld.bfd -shared %t1.o %t1.o # ok; STB_WEAK ``` If %t2.so has DT_NEEDED entries, ld.bfd will load them (lld/gold don't have the behavior). If one of the DSO defines foo and it is in the link-time search path (e.g. DT_NEEDED entry is an absolute path, via -rpath=, via -rpath-link=, etc), `ld.bfd %t1.o %t2.so` and `ld.bfd %t1.o %t2.so` will not error. In this patch, we make Undefined and SharedSymbol share the same binding computing logic. Case 1 will be allowed: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # ok; STB_WEAK; changed by this patch ``` In the future, we can explore the option that turns both (0,1) into errors if --no-allow-shlib-undefined (default when linking an executable) is in action. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65584 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368038 91177308-0d34-0410-b5e6-96231b3b80d8
The combineEhSections runs, by design, before processSectionCommands so that input exception sections like .ARM.exidx and .eh_frame are not assigned to OutputSections. Unfortunately if /DISCARD/ removes InputSections that have associated .ARM.exidx sections without discarding the .ARM.exidx synthetic section then we will end up crashing when trying to sort the InputSections in ascending address order. We fix this by filtering out the sections that have been discarded prior to processing the InputSections in finalizeContents(). fixes pr42890 Differential Revision: https://reviews.llvm.org/D65759 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368041 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR42759. ``` // If ifunc is taken address in -fPIC code, it may have a toc entry .section .toc,"aw",@progbits .quad ifunc // ifunc may be defined as STT_GNU_IFUNC in another object file .type ifunc, %gnu_indirect_function ``` If ifunc is non-preemptable (e.g. when linking an executable), the toc entry will be relocated by R_PPC64_IRELATIVE. R_*_IRELATIVE represents the symbolic value of a non-preemptable ifunc (not associated with a canonical PLT) in a writable location. It has an unknown value at link time, so we cannot apply toc-indirect to toc-relative relaxation. Reviewed By: luporl, sfertile Differential Revision: https://reviews.llvm.org/D65755 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368057 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: `createSyntheticSymbols`, which creates `WasmSym::InitTLS`, is only called when `!config->relocatable`, but this condition is not checked when calling `createInitTLSFunction`. This diff checks `!config->relocatable` before calling `createInitTLSFunction`. Fixes emscripten-core/emscripten#9155. Reviewers: tlively, aheejin, kripken, sbc100 Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65785 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368078 91177308-0d34-0410-b5e6-96231b3b80d8
… using operator<< The original patch broke buildbots, perhaps because it changed the default setting whether colors are enabled or not. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368131 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@368142 91177308-0d34-0410-b5e6-96231b3b80d8
I think --reproduce is no longer a debug-only option but a useful option that a common user may want to use. So, this patch updates the description of the option in the manual page. Differential Revision: https://reviews.llvm.org/D60557 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369740 91177308-0d34-0410-b5e6-96231b3b80d8
Building on D60557 mention the name of the linker generated contents of the reproduce archive, response.txt and version.txt. Also write a shorter description in the ld.lld --help that is closer to the documentation. Differential Revision: https://reviews.llvm.org/D66641 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369762 91177308-0d34-0410-b5e6-96231b3b80d8
…BITS Reported at https://reviews.llvm.org/D64930#1642223 If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss), we may not align its sh_offset. p_offset of the PT_LOAD will be set to sh_offset, and we will get p_offset!=p_vaddr (mod p_align). If such executable is mapped by the Linux kernel, it will segfault. After D64906, this may happen the non-linker script case. The linker script case has had this issue for a long time. This was fixed by rL321657 (but the test linkerscript/nobits-offset.s failed to test a SHT_NOBITS section), but broken by rL345154. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66658 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369828 91177308-0d34-0410-b5e6-96231b3b80d8
…. NFC git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369838 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369844 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369868 91177308-0d34-0410-b5e6-96231b3b80d8
--strip-all suppresses the creation of in.symtab
This can cause a null pointer dereference in OutputSection::finalize()
// --emit-relocs => copyRelocs is true
if (!config->copyRelocs || (type != SHT_RELA && type != SHT_REL))
return;
...
link = in.symTab->getParent()->sectionIndex; // in.symTab is null
Let's just disallow the combination. In some cases the combination can
cause GNU linkers to fail:
* ld.bfd: final link failed: invalid operation
* gold: internal error in set_no_output_symtab_entry, at ../../gold/object.h:1814
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D66704
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369878 91177308-0d34-0410-b5e6-96231b3b80d8
PR42990. For `SECTIONS { b = a; . = 0xff00 + (a >> 8); a = .; }`,
we currently set st_value(a)=0xff00 while st_value(b)=0xffff.
The following call tree demonstrates the problem:
```
link<ELF64LE>(Args);
Script->declareSymbols(); // insert a and b as absolute Defined
Writer<ELFT>().run();
Script->processSectionCommands();
addSymbol(cmd); // a and b are re-inserted. LinkerScript::getSymbolValue
// is lazily called by subsequent evaluation
finalizeSections();
forEachRelSec(scanRelocations<ELFT>);
processRelocAux // another problem PR42506, not affected by this patch
finalizeAddressDependentContent(); // loop executed once
script->assignAddresses(); // a = 0, b = 0xff00
script->assignAddresses(); // a = 0xff00, _end = 0xffff
```
We need another assignAddresses() to finalize the value of `a`.
This patch
1) modifies assignAddress() to track the original section/value of each
symbol and return a symbol whose section/value has changed.
2) moves the post-finalizeSections assignAddress() inside the loop
of finalizeAddressDependentContent() and makes it iterative.
Symbol assignment may not converge so we make a few attempts before
bailing out.
Note, assignAddresses() must be called at least twice. The penultimate
call finalized section addresses while the last finalized symbol values.
It is somewhat obscure and there was no comment.
linkerscript/addr-zero.test tests this.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D66279
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369889 91177308-0d34-0410-b5e6-96231b3b80d8
EhFrameSection::addSection checks liveness of FDE early. This makes it infeasible to move combineEhSections() before ICF. Postpone the check to EhFrameSection::finalizeContents(). This is what ARMExidxSyntheticSection does and it will make a subsequent patch D66717 simpler. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66727 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369890 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@369984 91177308-0d34-0410-b5e6-96231b3b80d8
…around. NFC. I've got another change that makes more use of this value in other places. Differential Revision: https://reviews.llvm.org/D66777 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370010 91177308-0d34-0410-b5e6-96231b3b80d8
…undefined Handling of --export/--undefined can pull in lazy symbols which in turn can pull in referenced to optional symbols. We need to delay the creation of optional symbols until all possible references to them have been created. Differential Revision: https://reviews.llvm.org/D66768 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370012 91177308-0d34-0410-b5e6-96231b3b80d8
Delete some insignificant addresses to make it simpler for layout changes. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370048 91177308-0d34-0410-b5e6-96231b3b80d8
Port the D64906 technique to ARM. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an arm binary decreases by at most 12kb. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66749 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370049 91177308-0d34-0410-b5e6-96231b3b80d8
32 bit unsigned, and 64 bit pointers. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370083 91177308-0d34-0410-b5e6-96231b3b80d8
Adds --growable-table flag to handle building wasm modules with tables that can grow. Wasm tables that we use to store function pointers. In order to add functions to that table at runtime, we need to either preallocate space, or grow the table. In order to specify a table with no maximum size, we need some flag to handle that case, separately from a potential --max-table-size= flag. Note that the number of elements in the table isn't knowable until link-time, so it's unclear if we will want a --max-table-size= flag in the future. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370127 91177308-0d34-0410-b5e6-96231b3b80d8
…bit signed," This reverts commit r370083 because it caused check-lld failures on sanitizer-x86_64-linux-fast. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370142 91177308-0d34-0410-b5e6-96231b3b80d8
… not exist This essentially reverts the code change of D63132 and switches to a simpler approach. In an executable/shared object, st_shndx of a symbol can be: 1) SHN_UNDEF: undefined symbol (or canonical PLT) 2) SHN_ABS: absolute symbol 3) any other value (usually a regular section index) represents a relative symbol. The actual value does not matter. Many ld.so (musl, all archs except MIPS of FreeBSD rtld-elf) even treat 2) and 3) the same. If .sdata does not exist, it does not matter what value/section __global_pointer$ has, as long as it is relative (otherwise there will be a pedantic lld error. See D63132). Just set the st_shndx arbitrarily to 1. Dummy st_shndx=1 may be used by __rela_iplt_start, linker-script-defined symbols outside a section, __dso_handle, etc. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66798 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370172 91177308-0d34-0410-b5e6-96231b3b80d8
…s on EM_AMDGPU and EM_SPARCV9 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370180 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by LemonBoy Differential Revision: https://reviews.llvm.org/D62185 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370183 91177308-0d34-0410-b5e6-96231b3b80d8
…RISCV Port the D64906 technique to RISC-V. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of a RISC-V binary decreases by at most 12kb. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370192 91177308-0d34-0410-b5e6-96231b3b80d8
r268231 made it so that the name of the --reproduce archive is no longer listed in the response file. Previously, with "--reproduce repro.tar" the response file would contain repro/home/.../llvm-build-dir/.../foo.o but after that change it contained home/.../llvm-build-dir/.../foo.o instead. The test added for this in r268231 checked that the response file doesn't contain the string "repro", but if the build dir is named e.g. "llvm-build-repro" then the test fails because of that. Change the assert to check that "repro" doesn't exist at the beginning of the line instead. I verified that the test still fails with r268231 reverted. The test technically still fails if someone builds llvm in a directory '/repro' below the root directory. Don't do that :) git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370211 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements support for the NO_STRIP flag, which will allow __attribute__((used)) to be implemented. This accompanies https://reviews.llvm.org/D62542, which moves to setting the NO_STRIP flag, and will continue to set EXPORTED for Emscripten targets for compatibility. Differential Revision: https://reviews.llvm.org/D66968 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370416 91177308-0d34-0410-b5e6-96231b3b80d8
Extend WindowsResourceParser to support using a ResourceSectionRef for loading resources from an object file. Only allow merging resource object files in mingw mode; keep the existing error on multiple resource objects in link mode. If there only is one resource object file and no .res resources, don't parse and recreate the .rsrc section, but just link it in without inspecting it. This allows users to produce any .rsrc section (outside of what the parser supports), just like before. (I don't have a specific need for this, but it reduces the risk of this new feature.) Separate out the .rsrc section chunks in InputFiles.cpp, and only include them in the list of section chunks to link if we've determined that there only was one single resource object. (We need to keep other chunks from those object files, as they can legitimately contain other sections as well, in addition to .rsrc section chunks.) Differential Revision: https://reviews.llvm.org/D66824 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370436 91177308-0d34-0410-b5e6-96231b3b80d8
D64136 and D65584, while fixing STB_WEAK issues and improving our compatibility with ld.bfd, can cause another STB_WEAK problem related to LTO: If %tundef.o has an undefined reference on f, and %tweakundef.o has a weak undefined reference on f, %tdef.o has a definition of f ``` ld.lld %tundef.o %tweakundef.o --start-lib %tdef.o --end-lib ``` 1) `%tundef.o` doesn't set the `referenced` bit. 2) `%weakundef.o` changes the binding from STB_GLOBAL to STB_WEAK 3) `%tdef.o` is not fetched because the binding is weak. Step (1) is incorrect. This patch sets the `referenced` bit of Undefined created by bitcode files. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66992 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370437 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This implements -start-lib and -end-lib flags for lld-link, analogous to the similarly named options in ld.lld. Object files after -start-lib are included in the link only when needed to resolve undefined symbols. The -end-lib flag goes back to the normal behavior of always including object files in the link. This mimics the semantics of static libraries, but without needing to actually create the archive file. Reviewers: ruiu, smeenai, MaskRay Reviewed By: ruiu, MaskRay Subscribers: akhuang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66848 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370487 91177308-0d34-0410-b5e6-96231b3b80d8
This should fix failing buildbots like http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/7180. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370491 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This a follow up on: https://reviews.llvm.org/D62153 Handle the case where there are multiple object files that contain undefined references to the same function. We only generate a function variant if the existing symbol is directly called. See: emscripten-core/emscripten#8995 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67015 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370509 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r370487 as it is causing ASan/MSan failures on sanitizer-x86_64-linux-fast git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370550 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.