Commit Graph

661 Commits

Author SHA1 Message Date
Fangrui Song ce5de93e83 [ELF] Disallow out-of-range section group indices after D70146
Exposed by invalid/sht-group-wrong-section.test
http://45.33.8.238/win/2613/step_9.txt
2019-11-19 09:49:45 -08:00
Fangrui Song 6b0eb5a672 [ELF] Improve --gc-sections compatibility with GNU ld regarding section groups
Based on D70020 by serge-sans-paille.

The ELF spec says:

> Furthermore, there may be internal references among these sections that would not make sense if one of the sections were removed or replaced by a duplicate from another object. Therefore, such groups must be included or omitted from the linked object as a unit. A section cannot be a member of more than one group.

GNU ld has 2 behaviors that we don't have:

- Group members (nextInSectionGroup != nullptr) are subject to garbage collection.
  This includes non-SHF_ALLOC SHT_NOTE sections.
  In particular, discarding non-SHF_ALLOC SHT_NOTE sections is an expected behavior by the Annobin
  project. See
  https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/
  for more information.
- Groups members are retained or discarded as a unit.
  Members may have internal references that are not expressed as
  SHF_LINK_ORDER, relocations, etc. It seems that we should be more conservative here:
  if a section is marked live, mark all the other member within the
  group.

Both behaviors are reasonable. This patch implements them.

A new field InputSectionBase::nextInSectionGroup tracks the next member
within a group. on ELF64, this increases sizeof(InputSectionBase) froms
144 to 152.

InputSectionBase::dependentSections tracks section dependencies, which
is used by both --gc-sections and /DISCARD/. We can't overload it for
the "next member" semantic, because we should allow /DISCARD/ to discard
sections independent of --gc-sections (GNU ld behavior). This behavior
may be reasonably used by `/DISCARD/ : { *(.ARM.exidx*) }` or `/DISCARD/
: { *(.note*) }` (new test `linkerscript/discard-group.s`).

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D70146
2019-11-19 08:54:06 -08:00
Reid Kleckner adfad4d7c8 Forward declare the DWARFCache to avoid including LLVM DWARF details
LLD's DWARF.h header leaks a lot of LLVM DWARF includes that LLD doesn't
need. For Chunks.cpp, I see a compile time decrease of 3.1s to 2.7s.
2019-11-14 14:17:49 -08:00
Nico Weber 5976a3f5aa Fix a few typos in lld/ELF to cycle bots 2019-10-28 21:41:47 -04:00
Fangrui Song 56d81104f1 [ELF] -r: fix crash when processing a SHT_REL[A] that relocates a SHF_MERGE after D67504/r372734
Fix PR43767

In -r mode, when processing a SHT_REL[A] that relocates a SHF_MERGE, sec->getRelocatedSection() is a
MergeInputSection and its parent is an OutputSection but is asserted to
be a SyntheticSection (MergeSyntheticSection) in LinkerScript.cpp:addInputSec().
 ##
The code path is not exercised in non -r mode because the relocated
section changed from MergeInputSection to InputSection.

Reorder the code to make the non -r logic apply to -r as well, thus fix
the crash.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D69364
2019-10-24 11:35:29 -07:00
Martin Storsjo 908b780952 [LLD] Move duplicated dwarf parsing code to the Common library. NFC.
Differential Revision: https://reviews.llvm.org/D69197

llvm-svn: 375390
2019-10-21 08:01:52 +00:00
Rui Ueyama d7ead5b58d Improve error message for bad SHF_MERGE sections
This patch adds a section name to error messages.

Differential Revision: https://reviews.llvm.org/D68758

llvm-svn: 374290
2019-10-10 08:32:12 +00:00
Fangrui Song bd8cfe65f5 [ELF] Wrap things in `namespace lld { namespace elf {`, NFC
This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.

Reviewed By: atanasyan, grimar, ruiu

Differential Revision: https://reviews.llvm.org/D68323

llvm-svn: 373885
2019-10-07 08:31:18 +00:00
Fangrui Song 688183ec54 [ELF] Set `referenced` bit of Undefined created by BitcodeFile
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

llvm-svn: 370437
2019-08-30 07:10:30 +00:00
Jonas Devlieghere 6ba7992031 [LLD] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368936
2019-08-14 22:28:17 +00:00
Fangrui Song ab04ad6af7 [ELF] Rename odd variable names "New" after r365730. NFC
New -> newSym or newFlags

Reviewed By: atanasyan

Differential Revision: https://reviews.llvm.org/D66127

llvm-svn: 368651
2019-08-13 06:19:39 +00:00
Fangrui Song e49c417ed1 [ELF] Make binding (weak or non-weak) logic consistent for Undefined 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

llvm-svn: 368038
2019-08-06 14:03:45 +00:00
Rui Ueyama d524c17029 Return early. NFC.
llvm-svn: 367200
2019-07-29 05:24:51 +00:00
Nico Weber 9c0716f116 ld.lld: Demangle symbols from archives in diagnostics
This ports r366573 from COFF to ELF.

There are now to toString(Archive::Symbol), one doing MSVC demangling
in COFF and one doing Itanium demangling in ELF, so rename these two
to toCOFFString() and to toELFString() to not get a duplicate symbol.

Nothing ever passes a raw Archive::Symbol to CHECK(), so these not
being part of the normal toString() machinery seems ok.

There are two code paths in the ELF linker that emits this type of
diagnostic:

1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test.

2. An additional one that's only used for libcalls if there's at least
   one bitcode in the link, and if the libcall symbol is lazy, and
   lazily loaded from an archive (i.e. not from a lazy .o file).
   (This code path was added in r339301.) Since all libcall names so far
   are C symbols and never mangled, the change there is not observable
   and hence not covered by tests.

Differential Revision: https://reviews.llvm.org/D65095

llvm-svn: 366836
2019-07-23 19:00:01 +00:00
Peter Collingbourne cb2d8e9125 ELF: Allow forward references to linked sections.
It's possible to create IR that uses !associated to refer to a global that
appears later in the module, which can result in these types of forward
references being generated. Unfortunately our assembler does not currently
accept the resulting .s so I needed to use yaml2obj to test this.

Differential Revision: https://reviews.llvm.org/D64880

llvm-svn: 366460
2019-07-18 16:47:29 +00:00
Fangrui Song 47cfe8f321 [ELF] Fix variable names in comments after VariableName -> variableName change
Also fix some typos.

llvm-svn: 366181
2019-07-16 05:50:45 +00:00
Rui Ueyama 49a3ad21d6 Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
    -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
    -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
    -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
    ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}

llvm-svn: 366177
2019-07-16 04:46:31 +00:00
Jonas Devlieghere ca16d280f7 Re-land "[DebugInfo] Move function from line table to the prologue (NFC)"
In LLDB, when parsing type units, we don't need to parse the whole line
table. Instead, we only need to parse the "support files" from the line
table prologue.

To make that possible, this patch moves the respective functions from
the LineTable into the Prologue. Because I don't think users of the
LineTable should have to know that these files come from the Prologue,

I've left the original methods in place, and made them redirect to the
LineTable.

Differential revision: https://reviews.llvm.org/D64774

llvm-svn: 366164
2019-07-16 01:21:25 +00:00
George Rimar 8d9b9f6bf2 [LLD][ELF] - Minor simplification. NFC.
This removes a call to `object::getSymbol<ELFT>`.
We used this function in a next way: it was given an
array of symbols and index and returned either a symbol
at the index given or a error.

This function was removed in D64631. 
(rL366052, but was reverted because of LLD compilation error
that I didn't know about).

It does not make much sense to keep this function on LLVM side
only for LLD, because having only a list of symbols and the index it
is not able to produce a valueable error message about context anyways.

llvm-svn: 366057
2019-07-15 11:47:54 +00:00
Rui Ueyama 136d27ab4d [Coding style change][lld] Rename variables for non-ELF ports
This patch does the same thing as r365595 to other subdirectories,
which completes the naming style change for the entire lld directory.

With this, the naming style conversion is complete for lld.

Differential Revision: https://reviews.llvm.org/D64473

llvm-svn: 365730
2019-07-11 05:40:30 +00:00
Rui Ueyama 3837f4273f [Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.

Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.

I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.

Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.

clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:

1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.

Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.

Differential Revision: https://reviews.llvm.org/D64121

llvm-svn: 365595
2019-07-10 05:00:37 +00:00
Rui Ueyama 11ae59f0ce Avoid identifiers that are different only in case. NFC.
Some variables in lld have the same name as functions ignoring case.
This patch gives them different names, so that my next patch is easier
to read.

llvm-svn: 365003
2019-07-03 06:11:50 +00:00
Kito Cheng eb9bc38276 [ELF][RISCV] Support RISC-V in getBitcodeMachineKind
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
2019-07-03 02:13:11 +00:00
Fangrui Song ba51fd5664 Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded
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
2019-06-26 08:09:08 +00:00
Hans Wennborg 36c23cad15 Revert r362743 "Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"""
(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
2019-06-25 14:58:46 +00:00
Peter Smith e208208a31 [ELF][AArch64] Support for BTI and PAC
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
2019-06-07 13:00:17 +00:00
Sean Fertile 6ba76dd779 Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded""
This reverts commit 729111cf1824159bb4dd331cab8a829eab30313f.

Reverting the previous commit breaks other LLD buildbots.

llvm-svn: 362743
2019-06-06 20:16:53 +00:00
Sean Fertile f1d9b3180e Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded"
This reverts commit 5d3b3188f7.

Breaks the PowerPC multi-stage buildbot.

llvm-svn: 362739
2019-06-06 19:34:26 +00:00
Sam Clegg 579c8df701 [lld] Explicitly ignore comdat groups when parsing LTO object(s)
Any symbols defined in the LTO object are by definition the ones we
want in the final output so we skip the comdat group checking in those
cases.

This change makes the ELF code more explicit about this and means
that wasm and ELF do this in the same way.

Differential Revision: https://reviews.llvm.org/D62884

llvm-svn: 362625
2019-06-05 17:39:37 +00:00
Peter Smith e12334a0f2 [ELF] Allow reading of more than one FEATURE_1_AND in same object.
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
2019-06-05 09:31:45 +00:00
Rui Ueyama 2057f8366a Read .note.gnu.property sections and emit a merged .note.gnu.property section.
This patch also adds `--require-cet` option for the sake of testing.
The actual feature for IBT-aware PLT is not included in this patch.

This is a part of https://reviews.llvm.org/D59780. Submitting this
first should make it easy to work with a related change
(https://reviews.llvm.org/D62609).

Differential Revision: https://reviews.llvm.org/D62853

llvm-svn: 362579
2019-06-05 03:04:46 +00:00
Fangrui Song 5d3b3188f7 Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded
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
2019-05-28 14:34:28 +00:00
Haojian Wu 241dcb386e Revert [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded
This reverts r361792 (git commit cfca5095df), the
revision causes link errors internally, will share more details with the
author.

llvm-svn: 361806
2019-05-28 11:21:59 +00:00
Fangrui Song cfca5095df [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded
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
2019-05-28 06:34:52 +00:00
Rui Ueyama 92069605bf Merge ELFFileBase::{initSymtab,parseHeader} as ELFFileBase:init. NFC.
This patch simplifies ELFFile instance initialization by merging
two similar functions into a single function and call it from the
ctor.

llvm-svn: 361789
2019-05-28 05:17:21 +00:00
Rui Ueyama 76737f4d19 Remove elf::createSharedFile and move its code to SharedFile's ctor. NFC.
llvm-svn: 361747
2019-05-27 07:26:13 +00:00
Rui Ueyama f5d9d23905 Simplify InputFile::fetch().
We don't have to return a value from the function. Instead, we can
directly call parseFile from the functions.

llvm-svn: 361478
2019-05-23 10:15:12 +00:00
Rui Ueyama 821a1ac050 Remove LazyObjFile::AddedToLink.
Instead we can just clear a MemoryBuffer so that we cannot get the
same buffer more than once.

llvm-svn: 361477
2019-05-23 10:08:56 +00:00
Rui Ueyama 7f7d2b2e62 Move code for symbol resolution from SymbolTable.cpp to Symbols.cpp.
My recent commits separated symbol resolution from the symbol table,
so the functions to resolve symbols are now in a somewhat wrong file.
This patch moves it to Symbols.cpp.

The functions are now member functions of the symbol.

This is code move change. I modified function names so that they are
appropriate as member functions, though. No functionality change
intended.

Differential Revision: https://reviews.llvm.org/D62290

llvm-svn: 361474
2019-05-23 09:58:08 +00:00
Rui Ueyama 4254840313 Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.

Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.

Previously, the feature was implemented this way:

 1. We read a symbol table and insert defined symbols to the symbol
    table as lazy symbols.

 2. If an undefind symbol is resolved to a lazy symbol, that lazy
    symbol instantiate ObjFile class for that symbol, which re-insert
    all defined symbols to the symbol table.

So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.

This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.

Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.

  Original: 5.892
    Case 1: 6.001 (+1.8%)
    Case 2: 5.701 (-3.2%)

So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.

Differential Revision: https://reviews.llvm.org/D62188

llvm-svn: 361473
2019-05-23 09:53:30 +00:00
Fangrui Song b72b091389 [ELF] Improve error message for relocations to symbols defined in discarded sections
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
2019-05-22 09:06:42 +00:00
Rui Ueyama 33e74d9f62 Simplify the logic to instantiate Symbols. Should be NFC.
llvm-svn: 361350
2019-05-22 04:56:25 +00:00
Ben Dunbobbin 1d16515fb4 [ELF] Implement Dependent Libraries Feature
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
2019-05-17 03:44:15 +00:00
Rui Ueyama bbf154cf9c Move symbol resolution code out of SymbolTable class.
This is the last patch of the series of patches to make it possible to
resolve symbols without asking SymbolTable to do so.

The main point of this patch is the introduction of
`elf::resolveSymbol(Symbol *Old, Symbol *New)`. That function resolves
or merges given symbols by examining symbol types and call
replaceSymbol (which memcpy's New to Old) if necessary.

With the new function, we have now separated symbol resolution from
symbol lookup. If you already have a Symbol pointer, you can directly
resolve the symbol without asking SymbolTable to do that.

Now that the nice abstraction become available, I can start working on
performance improvement of the linker. As a starter, I'm thinking of
making --{start,end}-lib faster.

--{start,end}-lib is currently unnecessarily slow because it looks up
the symbol table twice for each symbol.

 - The first hash table lookup/insertion occurs when we instantiate a
   LazyObject file to insert LazyObject symbols.

 - The second hash table lookup/insertion occurs when we create an
   ObjFile from LazyObject file. That overwrites LazyObject symbols
   with Defined symbols.

I think it is not too hard to see how we can now eliminate the second
hash table lookup. We can keep LazyObject symbols in Step 1, and then
call elf::resolveSymbol() to do Step 2.

Differential Revision: https://reviews.llvm.org/D61898

llvm-svn: 360975
2019-05-17 01:55:20 +00:00
Igor Kudrin 4669cf2750 [LTO] Improve readability of module IDs
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
2019-05-16 05:23:25 +00:00
Rui Ueyama 54ee6df247 Pemove SymbolTable::addBitcode as it is redundant.
Differential Revision: https://reviews.llvm.org/D61897

llvm-svn: 360846
2019-05-16 03:54:50 +00:00
Rui Ueyama 943cd00580 De-template parseFile() and SymbolTable's add-family functions.
Differential Revision: https://reviews.llvm.org/D61896

llvm-svn: 360844
2019-05-16 03:45:13 +00:00
Rui Ueyama 5c073a94f9 Introduce CommonSymbol.
Previously, we handled common symbols as a kind of Defined symbol,
but what we were doing for common symbols is pretty different from
regular defined symbols.

Common symbol and defined symbol are probably as different as shared
symbol and defined symbols are different.

This patch introduces CommonSymbol to represent common symbols.
After symbols are resolved, they are converted to Defined symbols
residing in a .bss section.

Differential Revision: https://reviews.llvm.org/D61895

llvm-svn: 360841
2019-05-16 03:29:03 +00:00
Rui Ueyama 7d4761928e Simplify SymbolTable::add{Defined,Undefined,...} functions.
SymbolTable's add-family functions have lots of parameters because
when they have to create a new symbol, they forward given arguments
to Symbol's constructors. Therefore, the functions take at least as
many arguments as their corresponding constructors.

This patch simplifies the add-family functions. Now, the functions
take a symbol instead of arguments to construct a symbol. If there's
no existing symbol, a given symbol is memcpy'ed to the symbol table.
Otherwise, the functions attempt to merge the existing and a given
new symbol.

I also eliminated `CanOmitFromDynSym` parameter, so that the functions
take really one argument.

Symbol classes are trivially constructible, so looks like constructing
them to pass to add-family functions is as cheap as passing a lot of
arguments to the functions. A quick benchmark showed that this patch
seems performance-neutral.

This is a preparation for
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html

Differential Revision: https://reviews.llvm.org/D61855

llvm-svn: 360838
2019-05-16 02:14:00 +00:00
Rui Ueyama 2dd5283d2a Move SymbolTable::addFile to InputFiles.cpp.
The symbol table used to be a container of vectors of input files,
but that's no longer the case because the vectors are moved out of
SymbolTable and are now global variables.

Therefore, addFile doesn't have to belong to any class. This patch
moves the function out of the class.

This patch is a preparation for my RFC [1].

[1] http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html

Differential Revision: https://reviews.llvm.org/D61854

llvm-svn: 360666
2019-05-14 12:03:13 +00:00
Rui Ueyama 0c01607bbf Rename a variable and add a comment.
llvm-svn: 358049
2019-04-10 06:32:05 +00:00
Rui Ueyama f432fa6eee De-template SymbolTable::addShared.
Because of r357925, this member function doesn't have to be a
template of ELFT.

llvm-svn: 357982
2019-04-09 08:52:00 +00:00
Peter Collingbourne d3e207057f ELF: Move verneed tracking data structures out of VersionNeedSection.
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
2019-04-08 17:48:05 +00:00
Peter Collingbourne cc1618e668 ELF: De-template SharedFile. NFCI.
Differential Revision: https://reviews.llvm.org/D60305

llvm-svn: 357925
2019-04-08 17:35:55 +00:00
Peter Collingbourne 883ab235ee ELF: De-template ELFFileBase. NFCI.
Differential Revision: https://reviews.llvm.org/D60304

llvm-svn: 357806
2019-04-05 20:16:26 +00:00
Peter Collingbourne ad4376e8af ELF: Simplify. NFCI.
Differential Revision: https://reviews.llvm.org/D60299

llvm-svn: 357739
2019-04-05 01:31:40 +00:00
Peter Collingbourne 8238604259 ELF: Move SymtabSHNDX and getSectionIndex() to ObjFile. NFCI.
Differential Revision: https://reviews.llvm.org/D60244

llvm-svn: 357670
2019-04-04 03:13:51 +00:00
Eli Friedman 3751ae4a94 [ELF] Print a better error for an archive containing a non-ELF file.
Hopefully gives a more readable error message for the most obvious
mistake.

Differential Revision: https://reviews.llvm.org/D59170

llvm-svn: 355888
2019-03-12 01:24:39 +00:00
Rui Ueyama 033c4d2126 Include an archive file name in an error message for a corrupted file.
Differential Revision: https://reviews.llvm.org/D59212

llvm-svn: 355886
2019-03-12 00:24:34 +00:00
Alexey Lapshin 77fc1f6049 [DebugInfo] add SectionedAddress to DebugInfo interfaces.
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
   "wrong line number info for obj file compiled with -ffunction-sections"
   bug. The problem happened with only .o files. If object file contains
   several .text sections then line number information showed incorrectly.
   The reason for this is that DwarfLineTable could not detect section which
   corresponds to specified address(because address is the local to the
   section). And as the result it could not select proper sequence in the
   line table. The fix is to pass SectionIndex with the address. So that it
   would be possible to differentiate addresses from various sections. With
   this fix llvm-objdump shows correct line numbers for disassembled code.

   Differential review: https://reviews.llvm.org/D58194

llvm-svn: 354972
2019-02-27 13:17:36 +00:00
Konstantin Zhuravlyov 87498153aa LLD/AMDGPU: Preserve ABI version during linking ELF for AMDGPU
Differential Revision: https://reviews.llvm.org/D58026

llvm-svn: 354086
2019-02-14 23:59:44 +00:00
Fangrui Song b4744d306c [ELF] Support --{,no-}allow-shlib-undefined
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
2019-02-01 02:25:05 +00:00
Nick Desaulniers 6cff0cb35a lld: elf: discard more specific .gnu.linkonce section
Summary:
lld discards .gnu.linonce.* sections work around a bug in glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=20543

Unfortunately, the Linux kernel uses a section named
.gnu.linkonce.this_module to store infomation about kernel modules. The
kernel reads data from this section when loading kernel modules, and
errors if it fails to find this section. The current behavior of lld
discards this section when kernel modules are linked, so kernel modules
linked with lld are unloadable by the linux kernel.

The Linux kernel should use a comdat section instead of .gnu.linkonce.
The minimum version of binutils supported by the kernel supports comdat
sections. The kernel is also not relying on the old linkonce behavior;
it seems to have chosen a name that contains a deprecated GNU feature.

Changing the section name now in the kernel would require all kernel
modules to be recompiled to make use of the new section name. Instead,
rather than discarding .gnu.linkonce.*, let's discard the more specific
section name to continue working around the glibc issue while supporting
linking Linux kernel modules.

Link: https://github.com/ClangBuiltLinux/linux/issues/329

Reviewers: pcc, espindola

Reviewed By: pcc

Subscribers: nathanchance, emaste, arichardson, void, srhines

Differential Revision: https://reviews.llvm.org/D57294

llvm-svn: 352302
2019-01-27 02:54:23 +00:00
Rui Ueyama e14e46b3f1 Simplify. NFC.
llvm-svn: 352242
2019-01-25 21:25:25 +00:00
Rui Ueyama ec33fd6dd5 Untabify.
llvm-svn: 352070
2019-01-24 18:17:17 +00:00
Serge Guelton 1fa239f500 Partial support of SHT_GROUP without flag
This does *not* implement full SHT_GROUP semantic, yet it is a simple step forward:
Sections within a group are still considered valid, but they do not behave as
specified by the standard in case of garbage collection.

Differential Revision: https://reviews.llvm.org/D56437

llvm-svn: 352068
2019-01-24 17:56:08 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
George Rimar 73af3d4060 [LLD][ELF] - Support MSP430.
Patch by Michael Skvortsov!

This change adds a basic support for linking static MSP430 ELF code.
Implemented relocation types are intended to correspond to the BFD.

Differential revision: https://reviews.llvm.org/D56535

llvm-svn: 350819
2019-01-10 13:43:06 +00:00
Rui Ueyama 2d7d128117 Use unique_ptr to manage a TarWriter instance. NFC.
llvm-svn: 349581
2018-12-18 23:50:37 +00:00
George Rimar 3608decaa5 [ELF] - Do not crash when -r output uses linker script with `/DISCARD/`
This is https://bugs.llvm.org/show_bug.cgi?id=39493.

We crashed previously because did not handle /DISCARD/ properly
when -r was used. I think it is uncommon to use scripts with -r, though I see
nothing wrong to handle the /DISCARD/ so that we will not crash at least.

Differential revision: https://reviews.llvm.org/D53864

llvm-svn: 345819
2018-11-01 09:20:06 +00:00
Sam Clegg ea65647254 Use llvm::arrayRefFromStringRef
Differential Revision: https://reviews.llvm.org/D53432

llvm-svn: 344888
2018-10-22 08:35:39 +00:00
Rui Ueyama 2600e0946b Rename SymbolTable::addRegular -> SymbolTable::addDefined.
We have addAbsolute, addBitcode, addCommon, etc. addRegular looked a
bit inconsistent.

llvm-svn: 344294
2018-10-11 20:43:01 +00:00
Rui Ueyama e28c146423 Avoid unnecessary buffer allocation and memcpy for compressed sections.
Previously, we uncompress all compressed sections before doing anything.
That works, and that is conceptually simple, but that could results in
a waste of CPU time and memory if uncompressed sections are then
discarded or just copied to the output buffer.

In particular, if .debug_gnu_pub{names,types} are compressed and if no
-gdb-index option is given, we wasted CPU and memory because we
uncompress them into newly allocated bufers and then memcpy the buffers
to the output buffer. That temporary buffer was redundant.

This patch changes how to uncompress sections. Now, compressed sections
are uncompressed lazily. To do that, `Data` member of `InputSectionBase`
is now hidden from outside, and `data()` accessor automatically expands
an compressed buffer if necessary.

If no one calls `data()`, then `writeTo()` directly uncompresses
compressed data into the output buffer. That eliminates the redundant
memory allocation and redundant memcpy.

This patch significantly reduces memory consumption (20 GiB max RSS to
15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total
5 GiB in an uncompressed form.

Differential Revision: https://reviews.llvm.org/D52917

llvm-svn: 343979
2018-10-08 16:58:59 +00:00
Shoaib Meenai 6883d882f1 [ELF] Fix crash on invalid undefined local symbols
r320770 made LLD handle invalid DSOs where local symbols were found in
the global part of the symbol table. Unfortunately, it didn't handle the
case where those local symbols were also undefined, and r326242 exposed
an assertion failure in that case. Just warn on that case instead of
crashing, by moving the local binding check before the undefined symbol
addition.

The input file for the test is crafted by hand, since I don't know of
any tool that would produce such a broken DSO. I also don't understand
what it even means for a symbol to be undefined but have STB_LOCAL
binding - I don't think that combination makes any sense - but we have
found broken DSOs of this nature that we were linking against. I've
included detailed instructions on how to produce the DSO in the test.

Differential Revision: https://reviews.llvm.org/D52815

llvm-svn: 343745
2018-10-03 23:53:11 +00:00
Michael J. Spencer 8222f902ca [ELF] Read the call graph profile from object files.
This uses the call graph profile embedded in the object files to construct the call graph.

This is read from a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).

Differential Revision: https://reviews.llvm.org/D45850

llvm-svn: 343552
2018-10-02 00:17:15 +00:00
Rui Ueyama 4e247522ac Reset input section pointers to null on each linker invocation.
Previously, if you invoke lld's `main` more than once in the same process,
the second invocation could fail or produce a wrong result due to a stale
pointer values of the previous run.

Differential Revision: https://reviews.llvm.org/D52506

llvm-svn: 343009
2018-09-25 19:26:58 +00:00
Rui Ueyama ae34348354 Fix an error message. It must start with a lowercase letter.
llvm-svn: 342992
2018-09-25 17:12:50 +00:00
Sean Fertile 69e09116ba [PPC64] Handle ppc64le triple in getBitcodeMachineKind.
Enables lto and thinlto with bitcode targeting ppc64le.

Differential Revision: https://reviews.llvm.org/D52265

llvm-svn: 342604
2018-09-20 00:26:49 +00:00
Fangrui Song 1fe3e8b26f [ELF] Check if LinkSec is nullptr when initializing SHF_LINK_ORDER sections
Summary: This protects lld from a null pointer dereference when a faulty input file has such invalid sh_link fields.

Reviewers: ruiu, espindola

Reviewed By: ruiu

Subscribers: emaste, arichardson, llvm-commits

Differential Revision: https://reviews.llvm.org/D51743

llvm-svn: 341611
2018-09-07 00:18:07 +00:00
Matt Arsenault 8d6c7a63a1 Handle identifying AMDGPU bitcode files
llvm-svn: 340738
2018-08-27 12:40:00 +00:00
Fangrui Song 887ec75173 [ELF] -thinlto-object-suffix-replace=: don't error if the path does not end with old suffix
Summary:
For -thinlto-object-suffix-replace=old\;new, in
tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus
optional old suffix.

    static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix,
                                                StringRef NewSuffix) {
      if (OldSuffix.empty() && NewSuffix.empty())
        return Path;
      StringRef NewPath = Path;
      NewPath.consume_back(OldSuffix);
      std::string NewNewPath = NewPath;
      NewNewPath += NewSuffix;
      return NewNewPath;
    }

Currently lld will error that the path does not end with old suffix.

This patch makes lld accept such paths but only add new suffix if Path
ends with old suffix. This fixes a link error where bitcode members in
an archive are regular LTO objects without old suffix.

Acording to tejohnson, this will "enable supporting mix and match of
minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a
single link (where we want to apply the suffix replacement to the
minimized files, and just ignore it for the normal ThinLTO files)."

Reviewers: ruiu, pcc, tejohnson, espindola

Reviewed By: tejohnson

Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D51055

llvm-svn: 340364
2018-08-21 23:28:12 +00:00
George Rimar e2684662ee [LLD][ELF] - Check the architecture of lazy objects earlier.
Our code in LazyObjFile::parse() has an ELFT switch and
adds a lazy object by its ELFT kind.
Though it might be possible to add a file using a different
architecture and make LLD to silently accept it (if the file
is empty or contains only week symbols). That itself, not a
huge issue perhaps (because the error would be reported later
if the file is fetched), but still does not look clean and correct.

It is possible to report an error earlier and clean up the
code. That is what the patch does.

Ideally, we might want to reuse isCompatible from SymbolTable.cpp,
but it is static and accepts a file as an argument, what is not
convenient. Since such a situation should be rare, I think it
should be OK to go with the way chosen in this patch.

Differential revision: https://reviews.llvm.org/D50899

llvm-svn: 340257
2018-08-21 08:13:06 +00:00
George Rimar bf6132c139 [LLD][ELF] - Remove dead code. NFC.
These lines were unused.

llvm-svn: 340011
2018-08-17 11:19:55 +00:00
George Rimar 2835606889 [LLD][ELF] - Handle SHT_GROUP more carefully. NFCI.
This patch solves 2 problems:
1) It adds a test to check the line below:
https://github.com/llvm-mirror/lld/blob/master/ELF/InputFiles.cpp#L334
Test case contains SHT_GROUP section with a broken (0xFF) flag.

2) The patch fixes the case when we silently accepted such broken groups
in the case when there were no other objects with the same group signature.

llvm-svn: 339765
2018-08-15 12:20:38 +00:00
George Rimar 830ff2d0b1 [LLD][ELF] - Remove redundant code. NFC.
Code was never executed with our test cases,
though it is valid and I think we can always run it.
This improves code coverage.

llvm-svn: 338708
2018-08-02 12:20:36 +00:00
Reid Kleckner c07f9bb83a Update for DWARF API change
llvm-svn: 338642
2018-08-01 21:57:15 +00:00
Peter Smith 70997f9a4e [ELF][ARM] Implement support for Tag_ABI_VFP_args
The Tag_ABI_VFP_args build attribute controls the procedure call standard
used for floating point parameters on ARM. The values are:
0 - Base AAPCS (FP Parameters passed in Core (Integer) registers
1 - VFP AAPCS (FP Parameters passed in FP registers)
2 - Toolchain specific (Neither Base or VFP)
3 - Compatible with all (No use of floating point parameters)

If the Tag_ABI_VFP_args build attribute is missing it has an implicit value
of 0.
    
We use the attribute in two ways:
- Detect a clash in calling convention between Base, VFP and Toolchain.
we follow ld.bfd's lead and do not error if there is a clash between an
implicit Base AAPCS caused by a missing attribute. Many projects
including the hard-float (VFP AAPCS) version of glibc contain assembler
files that do not use floating point but do not have Tag_ABI_VFP_args.
- Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag
for Base or VFP AAPCS respectively. This flag is used by some ELF
loaders.
    
References:
- Addenda to, and Errata in, the ABI for the ARM Architecture for
Tag_ABI_VFP_args
- Elf for the ARM Architecture for ELF header flags
    
Fixes PR36009
    
Differential Revision: https://reviews.llvm.org/D49993

llvm-svn: 338377
2018-07-31 13:41:59 +00:00
Peter Collingbourne a327a4c34e ELF: Implement --icf=safe using address-significance tables.
Differential Revision: https://reviews.llvm.org/D48146

llvm-svn: 337429
2018-07-18 22:49:31 +00:00
Sterling Augustine 4fd84c18df Implement framework for linking split-stack object files, and x86_64 support.
llvm-svn: 337332
2018-07-17 23:16:02 +00:00
George Rimar 484aabc818 [ELF] - Eliminate ObjFile<ELFT>::getLineInfo. NFC.
Flow is the same, but a bit shorter after this change.

llvm-svn: 337183
2018-07-16 15:29:35 +00:00
Rui Ueyama c020064655 Remove a dead variable.
llvm-svn: 334341
2018-06-09 00:54:18 +00:00
Han Shen 08d1640535 Correct aligment computation for shared object symbols.
The original computation for shared object symbol alignment is wrong when
st_value equals 0. It is very unusual for dso symbols to have st_value equal 0.
But when it happens, it causes obscure run time bugs.

Differential Revision: https://reviews.llvm.org/D47602

llvm-svn: 334135
2018-06-06 21:43:34 +00:00
George Rimar 64091d5626 [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages.
Currently, when LLD do a lookup for variables location, it uses DW_AT_name attribute.
That is not always enough.

Imagine code:

namespace A {
  int bar = 0;
}

namespace Z {
  int bar = 1;
}

int hoho;
In this case there are 3 variables and their debug attributes are following:

A::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x00000006] = "_ZN1A3barE")
Z::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0000003f] = "_ZN1Z3barE")
hoho has: DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004a] = "hoho") and has NO DW_AT_linkage_name attribute. Because it would be
the same as DW_AT_name and DWARF producers avoids emiting excessive data.

Hence LLD should also use DW_AT_linkage_name when it is available.
(currently, LLD fails to report location correctly because thinks that A::bar and Z::bar are the same things)

Differential revision: https://reviews.llvm.org/D47373

llvm-svn: 333880
2018-06-04 10:28:45 +00:00
Sam Clegg 3ad27e92bc Code cleanup in preparation for adding LTO for wasm. NFC.
- Move some common code into Common/rrorHandler.cpp and
  Common/Strings.h.
- Don't use `fatal` when incompatible bitcode files are
  encountered.
- Rename NameRef variable to just Name

See D47162

Differential Revision: https://reviews.llvm.org/D47206

llvm-svn: 333021
2018-05-22 20:20:25 +00:00
James Henderson 1a7aaf3cd5 [ELF] Update due to API change in .debug_line parsing
See r332845.

Reviewed by: grimar

Differential Revision: https://reviews.llvm.org/D46832

llvm-svn: 332846
2018-05-21 15:31:23 +00:00
Rui Ueyama 52d783962f Fix typo in error message.
llvm-svn: 332658
2018-05-17 20:25:35 +00:00
Rui Ueyama f06d494f46 Improve error message for -thinlto-object-suffix-replace and simplify code.
llvm-svn: 332643
2018-05-17 18:27:12 +00:00
Rumeet Dhindsa d2eb089a0e Add support for ThinLTO plugin option thinlto-object-suffix-replace
Differential Revision: https://reviews.llvm.org/D46608

llvm-svn: 332527
2018-05-16 21:04:08 +00:00
George Rimar 8f2b2f4e04 [ELF] - Simplify. NFC.
llvm-svn: 332242
2018-05-14 13:21:09 +00:00
James Henderson d621037788 [ELF] Rework debug line parsing to use llvm::Error and callbacks (LLD-side)
Reviewed by: ruiu, grimar, espindola

Differential Revision: https://reviews.llvm.org/D44562

Summary:
r331971 changes the debug line parser interface to report LLVM errors in an
interface that different executables can use, rather than always being printed
directly as warnings to stderr. This change allows LLD to make use of the new
interface and call its own warning methods to report problems.

llvm-svn: 331972
2018-05-10 10:52:21 +00:00