| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 353340
|
|
|
|
| |
llvm-svn: 353331
|
|
|
|
| |
llvm-svn: 353323
|
|
|
|
|
|
|
|
| |
They are defined by the x86-64 ELF ABI standard.
Differential Revision: https://reviews.llvm.org/D57799
llvm-svn: 353314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
It broke BB:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/43450
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/27891
Error is:
tools/lld/ELF/Config.h:84:41: error: copying member subobject of type
'std::atomic<bool>' invokes deleted constructor std::atomic<bool> HasStaticTlsModel = false;
llvm-svn: 353297
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 353272
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57725
llvm-svn: 353264
|
|
|
|
|
|
|
| |
The definition is harmful here as it suppresses R_PPC64_REL24 which is
supposed to follow R_PPC64_TLSLD.
llvm-svn: 353263
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57796
llvm-svn: 353254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a previous patch, I made changes so that PDBs which were
generated on non-Windows platforms contained sensical paths
for the host. While this is an esoteric use case, we need
it to be supported for certain cross compilation scenarios
especially with LLDB, which can debug things on non-Windows
platforms.
However, this regressed a case where you specify /PDBSOURCEPATH
and use a windows-style path. Previously, we would still remove
dots and canonicalize slashes to backslashes, but since my
change intentionally tried to support non-backslash paths, this
was broken.
This patch fixes the situation by trying to guess which path
style the user is specifying when /PDBSOURCEPATH is passed.
It is intentionally conservative, erring on the side of a
Windows path style unless absolutely certain. All dots are
removed and slashes canonicalized to whatever the deduced
path style is after appending the file path to the /PDBSOURCEPATH
argument.
Differential Revision: https://reviews.llvm.org/D57769
llvm-svn: 353250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
section-mapping
Summary:
The following patch adds the "None" line to the section to segment mapping dump.
That line lists the sections that do not belong to any segment.
I realize that this change differs from GNU readelf which does not display the latter information.
I'd rather not add this "feature" under a command line option. I think that might introduce confusion, since users would have to
make an additional decision as to if they want to see all of the section-to-segment map or just a subset of it.
Another option is to only print the "None" line if the `--section-mapping` option is passed; however,
that might also introduce some confusion, because the section-to-segment map would be different between`--program-headers`
and the `--section-mapping` output. While the difference is just the "None" line, it seems that if we choose to display
the segment-to-section mapping, then we should always display the whole map including the sections
that do not belong to segments.
```
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .gnu.hash
03 .init_array .fini_array .dynamic
04 .dynamic
05 .note.ABI-tag
06 .eh_frame_hdr
07
08 .init_array .fini_array .dynamic .got
None .comment .symtab .strtab .shstrtab <--- THIS LINE
```
Reviewers: grimar, rupprecht, jhenderson, espindola
Reviewed By: rupprecht
Subscribers: khemant, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57700
llvm-svn: 353217
|
|
|
|
| |
llvm-svn: 353200
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57758
llvm-svn: 353187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For MinGW, unique partial sections are much more common, e.g.
comdat functions get sections named e.g. text$symbol.
A moderate sized example of this contains over 200K Chunks
which create 174K unique PartialSections. Prior to SVN r352928
(D57574), linking this took around 1,5 seconds for me, while
it afterwards takes around 13 minutes. After this patch, the
linking time is back to what it was before.
The std::find_if in findPartialSection will do a linear scan of
the whole container until a match is found. To use something like
binary_search or the std::set container's own methods, we'd need
to already have a PartialSection*.
Reinstate a proper map instead of having a set with a custom sorting
comparator.
Differential Revision: https://reviews.llvm.org/D57666
llvm-svn: 353146
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR40582.
Patch by Georg Koppen!
Differential Revision: https://reviews.llvm.org/D57679
llvm-svn: 353145
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57715
llvm-svn: 353105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes clang-tidy warnings on wasm-only files.
The list of checks used is:
`-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming,modernize-*`
(LLVM's default .clang-tidy list is the same except it does not have
`modernize-*`.)
The list of fixes are:
- Variable names start with an uppercase letter
- Function names start with a lowercase letter
- Use `auto` when you use casts so the type is evident
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57499
llvm-svn: 353076
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57698
llvm-svn: 353066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
llvm-svn: 352943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ARM64, this is normally necessary only after a module exceeds
128 MB in size (while the limit for thumb is 16 MB). For conditional
branches, the range limit is only 1 MB though (the same as for thumb),
and for the tbz instruction, the range is only 32 KB, which allows for
a test much smaller than the full 128 MB.
This fixes PR40467.
Differential Revision: https://reviews.llvm.org/D57575
llvm-svn: 352929
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing a PDB, the OutputSection of all chunks need to be set.
The thunks are added directly to OutputSection after the normal
machinery that sets it for all other chunks.
This fixes part of PR40467.
Differential Revision: https://reviews.llvm.org/D57574
llvm-svn: 352928
|
|
|
|
| |
llvm-svn: 352887
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes: https://bugs.llvm.org/show_bug.cgi?id=37168
This is only a first pass at supporting these custom import
modules. In the long run we most likely want to treat these
kinds of symbols very differently. For example, it should not
be possible to resolve such as symbol at static link type.
Differential Revision: https://reviews.llvm.org/D45796
llvm-svn: 352828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
llvm-svn: 352826
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57555
llvm-svn: 352825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cl.exe and clang-cl.exe put vftables in a 'discard' comdat when building with
RTTI disabled (/GR-) but in a 'largest' comdat when building with RTTI enabled.
To be able to link /GR- code with /GR code, lld-link needs to accept comdats
that have this type of comdat selection conflict.
For example, static libraries in the Visual Studio standard library are built
with /GR, and without this it's impossible to build client code with /GR- and
still link to the standard library.
link.exe also accepts merging 'discard' with 'largest', and it accepts merging
'largest' with any other selection type. lld-link is still a bit stricter since
it only allows merging 'largest' with 'discard' for symmetry.
Differential Revision: https://reviews.llvm.org/D57515
llvm-svn: 352765
|
|
|
|
|
|
|
|
|
| |
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the way we create the symbol table to be closer to how its done
on ELF. Now the output symbol table matches the internal symtab order
and includes local and undefined symbols.
Fixes PR40204
Differential Revision: https://reviews.llvm.org/D56947
llvm-svn: 352645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After rLLD344952 ("Add OUTPUT_FORMAT linker script directive support"),
using BFD names such as `elf64-x86-64-freebsd` the `OUTPUT_FORMAT`
linker script command does not work anymore, resulting in errors like:
```
ld: error: /home/dim/src/clang800-import/stand/efi/loader/arch/amd64/ldscript.amd64:2: unknown output format name: elf64-x86-64-freebsd
>>> OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd")
>>> ^
```
To fix this, recognize a `-freebsd` suffix in BFD names, and also set
`Configuration::OSABI` to `ELFOSABI_FREEBSD` for those cases.
Add and/or update several test cases to check for the correct results of
these new `OUTPUT_FORMAT` arguments.
Reviewers: ruiu, atanasyan, grimar, hokein, emaste, espindola
Reviewed By: ruiu
Subscribers: nemanjai, javed.absar, arichardson, krytarowski, kristof.beyls, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D57283
llvm-svn: 352606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLD used to handle comdats as if the selection field was always set to
IMAGE_COMDAT_SELECT_ANY. This means for obj files produced by `cl /Gy`, LLD
would never report a duplicate symbol error.
This change:
- adds validation for the Selection field (should make no difference in
practice for compiler-generated obj inputs)
- rejects comdats that have different Selection fields in different obj files
(likewise). This is a bit more strict but also more self-consistent thank
link.exe (see comment in code)
- implements handling for all the selection kinds
In practice, compilers only generate comdats with
IMAGE_COMDAT_SELECT_NODUPLICATES (LLD now produces duplicate symbol errors for
these), IMAGE_COMDAT_SELECT_ANY (no behavior change), and
IMAGE_COMDAT_SELECT_LARGEST (for RTTI data; here LLD should no longer create
broken executables when linking some TUs with RTTI enabled and some with it
disabled – but see below).
The implementation of `IMAGE_COMDAT_SELECT_LARGEST` is incomplete: If one
SELECT_LARGEST comdat replaces an earlier one, the comdat symbol is replaced
correctly, but the old section stays loaded and if /opt:ref is disabled (via
/opt:noref or /debug) it's still written to the output. That's not ideal, but
better than the current treatment of just picking any one of those comdats. I
hope to fix this better later.
Fixes most of PR40094.
Differential Revision: https://reviews.llvm.org/D57324
llvm-svn: 352590
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46693
llvm-svn: 352589
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR40219
Subscribers: dschuff, mehdi_amini, inglorion, jgravelle-google, aheejin, sunfish, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D57420
llvm-svn: 352575
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR40494
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57370
llvm-svn: 352554
|
|
|
|
|
|
|
|
|
|
|
| |
Move them to the same section as the newly added ignored options
without a defined name.
Also move options that actually weren't ignored to the right section.
Differential Revision: https://reviews.llvm.org/D57374
llvm-svn: 352529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
References between associated comdats are invalid per COFF spec, but the newest
Windows SDK contains obj files that have these references
(https://bugs.chromium.org/p/chromium/issues/detail?id=925943#c13). So add back
support for them and add tests for them. The old code handled them fine.
This makes lld-link match the behavior of newer link.exe versions as far as I
can tell. (The behavior before this change matched the behavior of older
link.exe versions.)
This mostly reverts r352254.
Differential Revision: https://reviews.llvm.org/D57387
llvm-svn: 352508
|
|
|
|
| |
llvm-svn: 352499
|
|
|
|
|
|
| |
`readBfdName` was removed recently.
llvm-svn: 352482
|
|
|
|
|
|
|
|
|
|
| |
GCC can use LLD with -fuse-ld=lld for MinGW these days, but by
default these options are passed to the linker (unless -fno-lto
is passed to the GCC driver).
Differential Revision: https://reviews.llvm.org/D57304
llvm-svn: 352459
|
|
|
|
| |
llvm-svn: 352435
|
|
|
|
|
|
|
|
|
| |
Many different sections can have the same name, so include the indices of the
sections mentioned in the diagnostic too.
I'm debugging something I can't repro locally, maybe this will help.
llvm-svn: 352428
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were setting it to the GotPlt output section, which is
incorrect on ARM where this section is in .got. In static binaries
this can lead to sh_info being set to -1 (because there is no .got.plt)
which results in various tools rejecting the output file.
Differential Revision: https://reviews.llvm.org/D57274
llvm-svn: 352413
|
|
|
|
| |
llvm-svn: 352407
|
|
|
|
|
|
|
| |
r352366 "[llvm-objdump] - Print LMAs when dumping section headers." changed the format of
llvm-objdump output. We have to update the LLD tests.
llvm-svn: 352372
|
|
|
|
|
|
|
|
| |
Persist (input) sections that make up an OutputSection. This is a supporting patch for the upcoming D54802.
Differential Revision: https://reviews.llvm.org/D55293
llvm-svn: 352336
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57292
llvm-svn: 352325
|