For CloudABI I'm only interested in generating non-PIC/PIE executables
on armv6 and i686, as PIE introduces larger overhead than on aarch64 and
x86_64. Still, I want to be able to instruct the linker to generate a
dynamic symbol table if requested. One example use for this is that
dynamic symbol tables can be used by programs to print nicely formatted
stacktraces, including symbol names.

Right now there seems to be some logic in LLD that it only wants to emit
dynamic symbol tables when either linking against libraries or when
building PIC. Let's extend this to also take --export-dynamic into
account.

Reviewed by:	ruiu
Differential Revision:	https://reviews.llvm.org/D29982

llvm-svn: 295240

The linker script lexer is context-sensitive. In the regular context,
arithmetic operator characters are regular characters, but in the
expression context, they are independent tokens. This afects how the
lexer tokenizes "3*4", for example. (This kind of expression is real;
the Linux kernel uses it.)

This patch defines function `maybeSplitExpr`. This function splits the
current token into multiple expression tokens if the lexer is in the
expression context.

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

llvm-svn: 295225

If target of R_MIPS_GOT16 relocation is a local symbol its addend
is high 16 bits of complete addend. To calculate a final value, the addend
of this relocation is read, shifted to the left and combined with addend
of paired R_MIPS_LO16 relocation. To save updated addend when the linker
produces a relocatable output, we need to store high 16 bits of the
addend's value. It is different from the case of writing the relocation
result when the linker saves a 16-bit GOT index as-is.

llvm-svn: 295159

With this lld can use its own -r output when a fde is discarded.

llvm-svn: 295143

This is still not sufficient for lld to handle its own output when a
fde points to a discarded section. I am investigating if it is better
to change the -r output or make lld able to read the current version.

llvm-svn: 295141

This is a really horrible case. If a .eh_frame points to a discarded
section, it is not clear what is the correct thing to do.

It looks like ld.bfd discards the entire .eh_frame content and gold
discards the second relocation, leaving one frame with an fde that
refers to a bogus location. This is similar to what gold does.

llvm-svn: 295133

This reverts commit r295102.

In the link of seabios the assumption seems to be that the section has
an actual address, so this is not sufficient. Changing the assembly
code to add a "a" flag seems like the correct thing to do instead of
extending this hack.

Sorry about the noise.

Original message:

    Relax the restriction on what relocations can be in a non-alloc section.

    The main thing that they can't have is relocations that require the
    creation of gots or plt.  For now also accept R_PC.

    Found while linking seabios.

llvm-svn: 295130

If it is non-zero then objdump will print an empty name when printing
relocations against the section.

llvm-svn: 295129

I think this is more readable than before.

llvm-svn: 295121

The main thing that they can't have is relocations that require the
creation of gots or plt.  For now also accept R_PC.

Found while linking seabios.

llvm-svn: 295102

llvm-svn: 295077

If we had SHT_GROUP sections, then when -r was used we might crash.
This is PR31952.

Issue happened because we emited relocation section though its target was discared
because was a member of duplicated group. When we tried to get VA of target,
segfault happened.
Core cause is the bug that GNU as 2.27 (and probably later versions) has.
In compare with llvm-mc, it does not include relocation sections into the group, 
like shown in testcase. This patch covers that case.

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

llvm-svn: 295067

llvm-svn: 295062

Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.

The same we did earlier for PC ones,
currenly LLD fails to link linux kernel, 
reporting relocation out of range because of this.

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

llvm-svn: 295052

[ELF][MIPS] Use `InputSectionBase::getOutputSection()` to access output sections from the `MipsGotSection`

Follow-up to r294005. This patch restores handling of MISP GOT
relocations against merge sections.

llvm-svn: 295040

llvm-svn: 295031

llvm-svn: 295023

These files contain a lexer, so the new names are better.
The parser is in LinkerScript.{cpp,h}.

llvm-svn: 295022

Results created by these relocations are expected to be zero extended
at runtime.

llvm-svn: 294988

We were previously only reading the last one.

Fixes PR31939 (which was likely the issue underlying
https://github.com/google/oss-fuzz/issues/295).

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

llvm-svn: 294977

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

llvm-svn: 294971

It is used by qemu.

llvm-svn: 294965

Unfortunately some consumers of our .o files produced with -r expect
only one section symbol per section. That is true of at least of go's
own linker.

Combining them is a somewhat convoluted process. We have to create a
symbol for every section since we don't know which ones will be
needed. The relocation sections also have to be written first to
handle the Elf_Rel addend.

I did consider a completely different approach:

We could remove the -r special case of relocation sections when
reading. We would instead have a copyRelocs function that is used
instead of scanRelocs. It would create a DynamicReloc for each
relocation and a RelocationSection for each input relocation section.

A complication of such change is that DynamicReloc would have to take
a section index and a input section instead of a symbol since with
-emit-relocs some DynamicReloc would hold relocations referring to the
dynamic symbol table and other to the static symbol table.

That would be a pretty big change, and if we do it it is probably
better to do it as a refactoring.

llvm-svn: 294816

LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.

This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.

llvm-svn: 294690

In particular, this should allow us to gc unused asan metadata.

llvm-svn: 294592

    
Much of the code in PltSection and IPltSection is similar, we identify
the IPlt by a HeaderSize of 0 and alter our behaviour in the member
functions appropriately:
-Iplt does not have a header
-Iplt always follows after the Plt
    
Differential Revision: https://reviews.llvm.org/D29664

llvm-svn: 294579

    
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.

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

llvm-svn: 294577

Recommit r294464 "[ELF] - Added partial support for --emit-relocs (no --gc-section case, no /DISCARD/ support) #3"

with temporarily file name fix in testcase.

Original commit message:

-q, --emit-relocs - Generate relocations in output

Simplest implementation: 
* no GC case, 
* no "/DISCARD/" linkerscript command support.

This patch is extracted from D28612 / D29636,

Relative to PR31579.

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

llvm-svn: 294469

Reverted r294464 "[ELF] - Added partial support for --emit-relocs (no --gc-section case, no /DISCARD/ support) #3"

Broked build bot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/5835/steps/test/logs/stdio

llvm-svn: 294466

-q, --emit-relocs - Generate relocations in output

Simplest implementation: 
* no GC case, 
* no "/DISCARD/" linkerscript command support.

This patch is extracted from D28612 / D29636,

Relative to PR31579.

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

llvm-svn: 294464

This reverts commit r294346. Looks like it regressed the build of
magenta.

llvm-svn: 294460

OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)

We did not support that, because got 3 lexer tokens here after recent changes.

This trivial patch fixes the issue, now whole expression inside 
OUTPUT_ARCH is just ignored.

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

llvm-svn: 294432

LLD already parses ALIGN expression to specifiy alignment for output
sections in linker scripts but it never applies the alignment to the
output section. This change handles that.

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

llvm-svn: 294374

We now just keep the address the section would have if it was
allocatable. Only the writer ignores it at the very end.

llvm-svn: 294346

{ global : local; local: *; };

llvm-svn: 294343

DefinedSynthetic symbols are attached to sections,
for the case when such symbol was attached to non-allocated section,
we calculated its value incorrectly.

We subtracted Body->Section->Addr, but non-allocatable sections
should have zero VA in output and therefore result value was wrong.

And at the same time we have Body->Section->Addr != 0 for them 
internally because  use it for calculation of section size.

Patch fixes calculation of such symbols values.

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

llvm-svn: 294322

We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.

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

llvm-svn: 294290

Previously we did not do that. For example, for R_386_PC8, 
0xFF addend was not treated as 0xFFFFFFFF(-1), 
but was 0x000000FF.

Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation 
overflow as a result.

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

llvm-svn: 294289

If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.

llvm-svn: 294253

We now create a dummy section with index 1 before processing the
linker script.

Thanks to George Rimar for finding the bug and providing the initial
testcase.

llvm-svn: 294252