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

    
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

Fix the test zlib conditional to use LLVM_ENABLE_ZLIB value when
building stand-alone. The HAVE_LIBZ is not available when performing
a stand-alone build. Since the zlib support is a feature of
the underlying LLVM library, it exports the actual status as the final
value of LLVM_ENABLE_ZLIB in LLVMConfig.

While at it, canonicalize the boolean value into 0/1 and remove unused
CMake definitions (most likely copied from clang).

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

llvm-svn: 294508

Use both LLD- and LLVM-specific binary&library directories when LLD is
being built stand-alone. This ensures that the freshly built tools and
libraries are found and used correctly.

Without this patch, the test suite uses LLVM_TOOLS_DIR and LLVM_LIBS_DIR
to locate lld, and set PATH and LD_LIBRARY_PATH. When doing
a stand-alone builds, these variables represent the installed LLVM.
As a result, tests either fail due to missing lld executables/libraries
or use an earlier installed LLD version rather than the one being built.

To solve this, an additional LLD_TOOLS_DIR and LLD_LIBS_DIR variables
are added that are populated using LLVM_*_OUTPUT_INTDIR. Those variables
are populated with directories used to output built executables
and libraries. In stand-alone builds, they represent the directories
used by LLD. In integrated builds, they have the same values as
LLVM_*_DIR and therefore using them does not harm.

The new variables are prepended to PATH and LD_LIBRARY_PATH to ensure
that freshly built binaries are preferred over potentially earlier
installed ones. Furthermore, the resulting PATH is used to locate tools
for substitutions since the search includes both tools built as part of
LLD and of LLVM.

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

llvm-svn: 294507

The test is failing on the bot because "/subsystem:console" was
truncated for some reason. I don't know why that is happening on
that machine (it is not reproducible on my Windows machine).
In this patch, I'm trying to tame it by making the output shorter.

llvm-svn: 294502

Summary: This adds an option to save temporary files generated during link-time optimization. This can be useful for debugging.

Reviewers: ruiu, pcc

Reviewed By: ruiu, pcc

Subscribers: mehdi_amini

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

llvm-svn: 294498

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