llvm-svn: 295288

This patch removes NeedsCopyOrPltAddr and instead add two variables,
NeedsCopy and NeedsPltAddr. This uses one more bit in Symbol class,
but the actual size doesn't increase because we had unused bits.
This should improve code readability.

llvm-svn: 295287

llvm-svn: 295283

This is slightly inefficient than the previous code, but that is really
negligible as this function is usually called at most only a few times.

llvm-svn: 295282

llvm-svn: 295280

Previously, space in a BSS section for copy relocations are reserved
in a special way. We directly manipulated size of the BSS section.
r294577 changed the way of doing it. Now, we create an instance of
CopyRelSection (which is a synthetic input section) for each copy
relocation.

This patch removes the remains of the old way and add CopyRelSections
to BSS sections using `addSections` function, which is the usual
way to add an input section to an output section.

llvm-svn: 295278

In the target dependent code we already always return a int64_t. In
the target independent code we carefully use uintX_t, which has the
same result given 2 complement rules.

This just simplifies the code to use int64_t everywhere.

llvm-svn: 295263

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

llvm-svn: 295222

llvm-svn: 295221

Main intention of test was to check that 
we do not crash, but for additional check
it previously run readobj for input object
instead of output.

llvm-svn: 295161

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

The values being tested were not relevant to the test.

llvm-svn: 294776

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

llvm-svn: 294664

llvm-svn: 294659

 test/COFF/savetemps.ll

Reviewers: dyung, ruiu

Reviewed By: dyung, ruiu

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

llvm-svn: 294643

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