Commit Graph

12165 Commits

Author SHA1 Message Date
George Rimar f4f608d1f4 [LLD][ELF] - Replace invalid-e_shnum.s with YAML based version.
The previous version used a precompiled binary.

After this patch, we have no more precompiled binaries
in LLD ELF test suite :)

llvm-svn: 364529
2019-06-27 12:23:38 +00:00
Guanzhong Chen e15dc95466 [wasm-ld] Add __global_base symbol to mark the value of --global-base
Summary:
This is needed for address sanitizer on Emscripten. As everything in
memory starts at the value passed to --global-base, everything before
that can be used as shadow memory.

This symbol is added so that the library for the ASan runtime can know
where the shadow memory ends and real memory begins.

This is split from D63742.

Reviewers: tlively, aheejin, sbc100

Subscribers: sunfish, llvm-commits

Tags: #llvm

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

llvm-svn: 364467
2019-06-26 20:12:33 +00:00
Alexandre Ganea 90079977ac [LLD][COFF] Case insensitive compares for /nodefaultlib
Differential Revision: https://reviews.llvm.org/D63775

llvm-svn: 364438
2019-06-26 15:40:17 +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
Keno Fischer 5bb0dcd96e [WebAssembly] Fix accidental omission from rLLD364367
There was another place where handling for this relocation was missing
that was accidentally omitted from rLLD364367, causing the newly added
test to fail on the buildbots.

llvm-svn: 364371
2019-06-26 01:26:53 +00:00
Keno Fischer c5b8e1c538 [lld/WebAssembly] Slightly nicer error message for malformed input files
Summary:
Before:
```
wasm-ld: error: Relocations not in offset order
```
After
```
wasm-ld: error: While processing `libjulia.so`: Relocations not in offset order
```

At least this way you get to find out which input file is malformed.

Reviewers: sbc100
Differential Revision: https://reviews.llvm.org/D63694

llvm-svn: 364368
2019-06-26 00:52:46 +00:00
Keno Fischer cadcb9eb61 [WebAssembly] Fix list of relocations with addends in lld
Summary:
The list of relocations with addend in lld was missing `R_WASM_MEMORY_ADDR_REL_SLEB`,
causing `wasm-ld` to generate corrupted output. This fixes that problem and while
we're at it pulls the list of such relocations into the Wasm.h header, to avoid
duplicating it in multiple places.

Reviewers: sbc100
Differential Revision: https://reviews.llvm.org/D63696

llvm-svn: 364367
2019-06-26 00:52:42 +00:00
Sam Clegg 61d70e4a93 [WebAssembly] Error on archives without a symbol index
This is fairly common with wasm since GNU ar (most likely the system ar)
doesn't support the wasm object format so user who don't override AR
will end up with archives without an index.  We don't want to silently
ignore this issue.

In the future we could choose to instead behave like the ELF backend and
read the symbols from each object file in the archive if they are all of
the same type.  However, error'ing out seem like a conservative approach
for now.

Fixes: PR42376

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

llvm-svn: 364338
2019-06-25 17:49:35 +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
Nico Weber 0142b9ce31 Port r363962 to COFF: Deduplicate undefined symbol diagnostics
lld/coff already deduplicated undefined symbols on a TU level: It would
group all references to a symbol from a single TU. This makes it so that
references from all TUs to a single symbol are grouped together.

Since lld/coff almost did what I thought it did already, the patch is
much smaller than the elf version. The only not local change is that
getSymbolLocations() now returns a vector<string> instead of a string,
so that the undefined symbol reporting code can know how many references
to a symbol exist in a given TU.

Fixes PR42260 for lld/coff.

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

llvm-svn: 364285
2019-06-25 09:55:55 +00:00
Rui Ueyama e63ae7fee4 Fix an issue that common symbols are not internalized under some condition.
r360841 introduced CommonSymbol class. An unintended behavioral change
introduced by that change was that common symbols are not internalized
by LTO under some condition. This patch fixes that issue.

The issue occurred under the following condition:

  1. There exists a common symbol
  2. At least one DSO is given to lld or -pie is used

If the above conditions are met, Symbol::includeInDynsym() returned a
wrong value for a common symbol.

Fixes https://bugs.llvm.org/show_bug.cgi?id=41978

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

llvm-svn: 364273
2019-06-25 06:58:07 +00:00
Fangrui Song 2fb6b0f2ba [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.

The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.

The upper bound of the error message is not correct. Fix it as well.

The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.

Reviewed By: ruiu

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

llvm-svn: 364164
2019-06-24 05:37:20 +00:00
Nico Weber 2c45043415 lld/elf: Deduplicate undefined symbol diagnostics
Before:

```
ld.lld: error: undefined symbol: f()
>>> referenced by test.cc:3
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(g())

ld.lld: error: undefined symbol: f()
>>> referenced by test.cc:4
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(h())

ld.lld: error: undefined symbol: f()
>>> referenced by test.cc:5
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j())

ld.lld: error: undefined symbol: k()
>>> referenced by test.cc:5
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j())

ld.lld: error: undefined symbol: f()
>>> referenced by test2.cc:2
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-07b391.o:(asdf())
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

Now:

```
ld.lld: error: undefined symbol: f()
>>> referenced by test.cc:3
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(g())
>>> referenced by test.cc:4
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(h())
>>> referenced by test.cc:5
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j())
>>> referenced by test2.cc:2
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-6bdb24.o:(asdf())

ld.lld: error: undefined symbol: k()
>>> referenced by test.cc:5
>>>               /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j())
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

If there are more than 10 references to an undefined symbol, only the
first 10 are printed.

Fixes PR42260.

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

llvm-svn: 363962
2019-06-20 18:25:57 +00:00
Fangrui Song 249fde8583 [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections
Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.

This patch is an attempt to simplify the logic.

Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.

Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.

For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.

Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.

Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola

Reviewed By: ruiu

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

llvm-svn: 363928
2019-06-20 14:00:08 +00:00
Fangrui Song ffed2c96d9 [ELF][ARM] Merge handleARMTlsRelocation() into handleTlsRelocation()
ARM and RISC-V do not support TLS relaxations. However, for General
Dynamic and Local Dynamic models, if we are producing an executable and
the symbol is non-preemptable, we know it must be defined and the
R_ARM_TLS_DTPMOD32/R_RISCV_TLS_DTPMOD{32,64} dynamic relocation can be
omitted because it is always 1. This may be necessary for static linking
as DTPMOD may not be expected at load time.

Merge handleARMTlsRelocation() into handleTlsRelocation(). This requires
more logic to R_TLSGD_PC and R_TLSLD_PC. Because we use SymbolicRel to
resolve the relocation at link time, R_ARM_TLS_DTPMOD32 can be deleted
from relocateOne(). It cannot be used as a static relocation type.

As a bonus, the additional logic in R_TLSGD_PC code can be shared by the
TLS support for RISC-V (D63220).

Reviewed By: ruiu

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

llvm-svn: 363927
2019-06-20 13:53:11 +00:00
Yuanfang Chen 40a156b791 [llvm-readobj] Match GNU output for DT_RPATH and DT_RUNPATH when dumping dynamic symbol table.
Reviewers: jhenderson, grimar, MaskRay, rupprecht, espindola

Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits

Tags: #llvm

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

llvm-svn: 363868
2019-06-19 19:31:07 +00:00
Reid Kleckner a702f07301 [PDB] Ignore .debug$S subsections with high bit set
Some versions of the Visual C++ 2015 runtime have line tables with the
subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to
be DEBUG_S_IGNORE. This appears to implement the intended behavior.

llvm-svn: 363724
2019-06-18 19:41:25 +00:00
Francis Visoiu Mistrih 34667519dc [Remarks] Extend -fsave-optimization-record to specify the format
Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.

For now, only YAML is supported.

llvm-svn: 363573
2019-06-17 16:06:00 +00:00
Fangrui Song 46f9cbe28d [llvm-objdump] Use %08 instead of %016 to print leading addresses for 32-bit binaries
Reviewed By: grimar

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

llvm-svn: 363539
2019-06-17 09:59:55 +00:00
Reid Kleckner 05e48cb9fa Include the file in the new unknown codeview subsection warning
llvm-svn: 363466
2019-06-14 22:03:23 +00:00
Martin Storsjo 2de984cd30 [COFF] Strip section name suffix from mingw comdats
This is the second part of the fix for PR42217.

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

llvm-svn: 363457
2019-06-14 21:02:09 +00:00
Martin Storsjo c3b1d730d6 [COFF] Handle .eh_frame$symbol as associative comdat for MinGW
This matches how it is done for .xdata and .pdata already.

On i386, the symbol name in the section name suffix does not contain
the extra underscore prefix.

This is one part of a fix for PR42217.

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

llvm-svn: 363456
2019-06-14 21:02:04 +00:00
Martin Storsjo ff4e0a9f3e [MinGW] Support the --subsystem=val option in joined form
Differential Revision: https://reviews.llvm.org/D63250

llvm-svn: 363433
2019-06-14 17:50:39 +00:00
Martin Storsjo 6f047ae58b [MinGW] Support the --{major,minor}-{os,subsystem}-version options
This fixes PR42218.

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

llvm-svn: 363432
2019-06-14 17:50:35 +00:00
Martin Storsjo b20fefc89b [COFF] Allow setting subsystem versions while inferring the subsystem type implicitly
Differential Revision: https://reviews.llvm.org/D63248

llvm-svn: 363431
2019-06-14 17:50:29 +00:00
Nico Weber bea1286155 Wrap a test to 80 columns
llvm-svn: 363421
2019-06-14 16:47:07 +00:00
Nico Weber 96a15796fb Remove two unused parameters
llvm-svn: 363419
2019-06-14 16:46:02 +00:00
George Rimar 76d575312d [LLD][ELF] - Fix test case after r363401
llvm-svn: 363402
2019-06-14 14:26:34 +00:00
Fangrui Song e05ca38101 [ELF] Don't emit dynamic relocations with weak undef in writable sections
In processRelocAux(), our handling of 1) link-time constant and 2) weak
undef is the same, so put them together to simplify the logic.

This moves the weak undef code around. The result is that: in a writable
section (or -z notext), we will no longer emit dynamic relocations for
weak undefined symbols.

The new behavior seems to match GNU linkers, and improves consistency
with the case of a readonly section.

The condition `!Config->Shared` was there probably because it is common
for a -shared link not to specify full dependencies. Keep it now but we
may revisit the decision in the future.

gABI says:

> The behavior of weak symbols in areas not specified by this document is
> implementation defined. Weak symbols are intended primarily for use in
> system software. Applications using weak symbols are unreliable since
> changes in the runtime environment might cause the execution to fail.

Reviewed By: ruiu

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

llvm-svn: 363399
2019-06-14 14:09:15 +00:00
George Rimar a59bc6e589 Revert r363395.
It will not work because of r363394.

llvm-svn: 363398
2019-06-14 14:06:03 +00:00
Nico Weber a35b935d39 lld/coff: slightly simplify ImportFile::parse()
llvm-svn: 363397
2019-06-14 14:03:08 +00:00
Rui Ueyama 43f4b037d5 Add --undefined-glob which is an --undefined with wildcard pattern match
This patch adds new command line option `--undefined-glob` to lld.
That option is a variant of `--undefined` but accepts wildcard
patterns so that all symbols that match with a given pattern are
handled as if they were given by `-u`.

`-u foo` is to force resolve symbol foo if foo is not a defined symbol
and there's a static archive that contains a definition of symbol foo.

Now, you can specify a wildcard pattern as an argument for `--undefined-glob`.
So, if you want to include all JNI symbols (which start with "Java_"), you
can do that by passing `--undefined-glob "Java_*"` to the linker, for example.

In this patch, I use the same glob pattern matcher as the version script
processor is using, so it does not only support `*` but also `?` and `[...]`.

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

llvm-svn: 363396
2019-06-14 14:00:59 +00:00
George Rimar a0b0d626ab [ELF] - Attemp to fix BB.
Seems section has a wrong type.

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/28

llvm-svn: 363395
2019-06-14 13:59:27 +00:00
Fangrui Song 5b4285d82d [ELF][RISCV] Create dummy .sdata for __global_pointer$ if .sdata does not exist
If .sdata is absent, linker synthesized __global_pointer$ gets a section index of SHN_ABS.
(ld.bfd has a similar issue: binutils PR24678)

Scrt1.o may use `lla gp, __global_pointer$` to reference the symbol PC
relatively. In -pie/-shared mode, lld complains if a PC relative
relocation references an absolute symbol (SHN_ABS) but ld.bfd doesn't:

    ld.lld: error: relocation R_RISCV_PCREL_HI20 cannot refer to lute symbol: __global_pointer$

Let the reference of __global_pointer$ to force creation of .sdata to
fix the problem. This is similar to _GLOBAL_OFFSET_TABLE_, which forces
creation of .got or .got.plt .

Also, change the visibility from STV_HIDDEN to STV_DEFAULT and don't
define the symbol for -shared. This matches ld.bfd, though I don't
understand why it uses STV_DEFAULT.

Reviewed By: ruiu, jrtc27

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

llvm-svn: 363351
2019-06-14 02:14:53 +00:00
Eugene Leviant 0eb763c559 [lld][ELF] Add tests for bad subsection length in .ARM.attributes
Differential revision: https://reviews.llvm.org/D63191

llvm-svn: 363261
2019-06-13 13:41:28 +00:00
Fangrui Song a78e025558 [ELF] Loosen the condition that changes absolute relocation types to relative relocations for ARM and PPC64
Try fixing build bots after D63121

llvm-svn: 363236
2019-06-13 08:45:22 +00:00
Reid Kleckner 5584ab89a8 [lld] Fix type server merging with PDBs without IPI stream
PDBs may not necessarily contain an IPI stream. Handle this case
gracefully.

The test case was verified to work with MS link.exe.

Patch by Vladimir Panteleev, with a small simplification

Reviewed By: rnk

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

llvm-svn: 363213
2019-06-12 22:33:16 +00:00
Reid Kleckner efc01eac17 [lld] Allow unrecognized signatures in debug sections
An unrecognized signature (magic) at the beginning of a debug section
should not be a fatal error; it only means that the debug information
is in a format that is not supported by LLD. This can be due to it
being in CodeView versions 3 or earlier. These can occur in old import
libraries from legacy SDKs.

The test case was verified to work with MS link.exe.

Patch by Vladimir Panteleev!

Reviewed By: rnk

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

llvm-svn: 363212
2019-06-12 22:22:44 +00:00
Nico Weber 1dc2123d64 Share /machine: handling code with llvm-cvtres too
r363016 let lld-link and llvm-lib share the /machine: parsing code.
This lets llvm-cvtres share it as well.

Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't
need llvm-lib's dependencies on BinaryFormat and BitReader) and I
couldn't find a good place to put this code. Since it's just a few
lines, put it in lib/Object for now.

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

llvm-svn: 363144
2019-06-12 11:32:43 +00:00
Fangrui Song 4ce0a519c1 [ELF][RISCV] Treat R_RISCV_{ADD,SET,SUB}* as link-time constants
R_RISCV_{ADD,SET,SUB}* are used for local label computation.
Add a new RelExpr member R_RISCV_ADD to represent them.

R_RISCV_ADD is treated as a link-time constant because otherwise
R_RISCV_{ADD,SET,SUB}* are not allowed in -pie/-shared mode.
In glibc Scrt1.o, .rela.eh_frame contains such relocations.
Because .eh_frame is not writable, we get this error:

    ld.lld: error: can't create dynamic relocation R_RISCV_ADD32 against symbol: .L0 in readonly segment; recompil object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
    >>> defined in ..../riscv64-linux-gnu/lib/Scrt1.o

With D63076 and this patch, I can run -pie/-shared programs linked against glibc.

Note llvm-mc cannot currently produce R_RISCV_SET* so they are not tested.

Reviewed By: ruiu

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

llvm-svn: 363128
2019-06-12 07:53:06 +00:00
Fangrui Song 11549e5c46 [ELF][PPC64] Don't report "relocation refers to a discarded section" for .toc
Summary:
clang (as of 2019-06-12) / gcc (as of 8.2.1) PPC64 may emit a .rela.toc
which references an embedded switch table in a discarded .rodata/.text
section. The .toc and the .rela.toc are incorrectly not placed in the
comdat.

Technically a relocation from outside the group is not allowed by the ELF spec:

> A symbol table entry with STB_LOCAL binding that is defined relative
> to one of a group's sections, and that is contained in a symbol table
> section that is not part of the group, must be discarded if the group
> members are discarded. References to this symbol table entry from
> outside the group are not allowed.

Don't report errors to work around the bug.

This should fix the ppc64le-lld-multistage-test bot while linking llvm-tblgen:

    ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv
    >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o
    >>> referenced by CodeGenRegisters.cpp
    >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0)

Some other PPC specific sections may have similar problems. We can blacklist more
section names when problems occur.

    // A simple program that reproduces the bug.
    // Note .rela.toc (outside the group) references a section symbol (STB_LOCAL) in a group.
    void puts(const char *);
    struct A {
      void foo(int a) {
        switch (a) {
        case 0: puts("0"); break;
        case 1: puts("1"); puts("1"); break;
        case 2: puts("2"); break;
        case 3: puts("3"); puts("4"); break;
        case 4: puts("4"); break;
        case 5: puts("5"); puts("5"); break;
        case 6: puts("6"); break;
        }
      }
      int a;
    };
    void foo(A x) { x.foo(x.a); }

Reviewers: ruiu, sfertile, espindola

Reviewed By: ruiu

Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 363126
2019-06-12 07:35:42 +00:00
Fangrui Song 8a529f3cea Revert "Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16"
This reverts commit r363060 and restores r362867.

r362867 is innocent. The ppc64le-lld-multistage-test bot failure was due to a clang/gcc .toc bug:

    ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv
    >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o
    >>> referenced by CodeGenRegisters.cpp
    >>>               utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0)

It will be worked around by D63182.

llvm-svn: 363124
2019-06-12 06:00:39 +00:00
Amy Huang 9970817c57 Deduplicate S_CONSTANTs in LLD.
Summary: Deduplicate S_CONSTANTS when linking, if they have the same value.

Reviewers: rnk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 363089
2019-06-11 18:02:39 +00:00
Nico Weber af6bc65ddf lld-link: Reject more than one resource .obj file
Users are exepcted to pass all .res files to the linker, which then
merges all the resource in all .res files into a tree structure and then
converts the final tree structure to a .obj file with .rsrc$01 and
.rsrc$02 sections and then links that.

If the user instead passes several .obj files containing such resources,
the correct thing to do would be to have custom code to merge the trees
in the resource sections instead of doing normal section merging -- but
link.exe rejects if multiple resource obj files are passed in with
LNK4078, so let lld-link do that too instead of silently writing broken
.rsrc sections in that case.

The only real way to run into this is if users manually convert .res
files to .obj files by running cvtres and then handing the resulting
.obj files to lld-link instead, which in practice likely never happens.

(lld-link is slightly stricter than link.exe now: If link.exe is passed
one .obj file created by cvtres, and a .res file, for some reason it
just emits a warning instead of an error and outputs strange looking
data. lld-link now errors out on mixed input like this.)

One way users could accidentally run into this is the following
scenario: If a .res file is passed to lib.exe, then lib.exe calls
cvtres.exe on the .res file before putting it in the output .lib.
(llvm-lib currently doesn't do this.)
link.exe's /wholearchive seems to only add obj files referenced from the
static library index, but lld-link current really adds all files in the
archive. So if lld-link /wholearchive is used with .lib files produced
by lib.exe and .res files were among the files handed to lib.exe, we
previously silently produced invalid output, but now we error out.

link.exe's /wholearchive semantics on the other hand mean that it
wouldn't load the resource object files from the .lib file at all.
Since this scenario is probably still an unlikely corner case,
the difference in behavior here seems fine -- and lld-link might have to
change to use link.exe's /wholearchive semantics in the future anyways.

Vaguely related to PR42180.

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

llvm-svn: 363078
2019-06-11 15:22:28 +00:00
Fangrui Song 47d77365aa [ELF][RISCV] Add R_RISCV_PC_INDIRECT to isRelExpr()
So that R_RISCV_PCREL_LO12_[IS] are considered as link-time constants in
-pie mode, otherwise there are bogus errors:

    ld.lld: error: can't create dynamic relocation R_RISCV_PCREL_LO12_I against symbol: .L0  in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output

Reviewed By: ruiu

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

llvm-svn: 363064
2019-06-11 13:39:08 +00:00
Rui Ueyama 963d73ff44 Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16
This reverts commit r362867 since it seems to have broken
ppc64le-lld-multistage-test bot.

llvm-svn: 363060
2019-06-11 13:00:52 +00:00
Fangrui Song 025a815d75 [ELF] Make the rule to create relative relocations in a writable section stricter
The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`.

When the symbol is non-preemptable, this allows absolute relocation
types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are
disallowed by ld.bfd and gold, e.g.

    ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC

This patch:

a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a
symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64).

  As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve
  GOT slots that are link-time constants. Since we now use Target->SymbolRel
  to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets.
  R_*_GLOB_DAT cannot be used as static relocation types.
b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`.

Some tests are caught by the improved error checking (ld.bfd/gold also
issue errors on them). Many misuse .long where .quad should be used
instead.

Reviewed By: ruiu

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

llvm-svn: 363059
2019-06-11 12:59:30 +00:00
Nico Weber dd6019526d Let writeWindowsResourceCOFF() take a TimeStamp parameter
For lld, pass in Config->Timestamp (which is set based on lld's
/timestamp: and /Brepro flags). Since the writeWindowsResourceCOFF()
data is only used in-memory by LLD and the obj's timestamp isn't used
for anything in the output, this doesn't change behavior.

For llvm-cvtres, add an optional /timestamp: parameter, and use the
current behavior of calling time() if the parameter is not passed in.

This doesn't really change observable behavior (unless someone passes
/timestamp: to llvm-cvtres, which wasn't possible before), but it
removes the last unqualified call to time() from llvm/lib, which seems
like a good thing.

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

llvm-svn: 363050
2019-06-11 11:26:50 +00:00
Peter Collingbourne eaf3f56924 ELF: Don't process the partition end marker during combineEhSections().
Otherwise the getPartition() accessor may return an OOB pointer. Found
using _GLIBCXX_DEBUG.

The error is benign (we never dereference the pointer for the end marker)
so this wasn't caught by e.g. the sanitizer bots.

llvm-svn: 363026
2019-06-11 02:54:30 +00:00
Fangrui Song fc2b5c40ae Fix -DBUILD_SHARED_LIBS=on build after r362977
The executable has an undefined reference to lld::Saver, the library
should be explicitly linked.

llvm-svn: 363023
2019-06-11 01:50:58 +00:00