Behavior races on ErrorCount. If the enqueued paths are evaluated
eagerly (in enqueuePath) then the behavior is as the test expects. But
they may not be evaluated until the future is waited on, in run() -
which is after the early return/exit on ErrorCount. (this causes the
test to fail (because in the "/ERRORCOUNT:XYZ" test, no other errors
are printed), at least for me, on linux)

This reverts commit r295507.

llvm-svn: 295590

Summary: This adds support for reporting multiple errors in a single invocation of lld-link. The limit defaults to 20 and can be changed with the /ERRORLIMIT command line parameter, or set to unlimited by passing a value of 0.

Reviewers: pcc, ruiu

Reviewed By: ruiu

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

llvm-svn: 295507

Previously LLD crashed on on provided testcases because "/DISCARD/" was
not supported. Patch implements that.

After this I think there is no known issues with --emit-relocs implementation
required for linux kernel linking.

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

llvm-svn: 295488

Before it would never print anything.

Thanks to George Rimar for pointing it out.

llvm-svn: 295485

I splitted it from D29273.
Since we plan to make relocatable sections as dependent for target ones for
--emit-relocs implementation, this change is required to support .eh_frame case.

EhInputSection inherets from InputSectionBase and not from InputSection.
So for case when it has relocation section, it should be able to access DependentSections
vector.

This case is real for Linux kernel.

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

llvm-svn: 295483

This is a small difference I noticed to gold and bfd. When given
--print-gc-sections, we print sections a linkerscript marks
DISCARD. The other linkers don't.

llvm-svn: 295467

This case should be possible to handle, but it is hard:

* In order to create program headers correctly, we have to scan the
  sections in the order they are in the file.

* To find that order, we have to "execute" the linker script.

* The linker script can contain SIZEOF_HEADERS.

So to support this we have to start with a guess of how many headers
we need (3), run the linker script and try to create the program
headers. If it turns out we need more headers, we run the script again
with a larger SIZEOF_HEADERS.

Also, running the linker script depends on knowing the size of the
sections, so we have to finalize them. But creating the program
headers can change the value stored in some sections, so we have to
split size finalization and content finalization.

Looks like the last part is also needed for range extension thunks, so
we might support this at some point. For now just report an error
instead of producing broken files.

llvm-svn: 295458

We were only checking when the assignment was inside a section.

llvm-svn: 295454

llvm-svn: 295448

The previous name caused a little confusion because the function not
only returns aliases but a given symbol itself too.

llvm-svn: 295408

llvm-svn: 295388

Without this we would produce two relocation sections pointing to the
same section, which gnu tools reject.

This fixes pr31986.

The implementation of -r/--emit-reloc is getting fairly
complicated. But lets get the test passing before trying to refactor
it.

llvm-svn: 295385

Some PDBs or object files can contain references to other PDBs
where the real type information lives.  When this happens,
all type indices in the original PDB are meaningless because
their records are not there.

With this patch we add the ability to pull type info from those
secondary PDBs.

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

llvm-svn: 295382

I cannot reproduce the issue locally, but for some reason some bots
want to instantiate this from the header.

llvm-svn: 295365

We can do this now that the linker script and the writer agree on
which sections should be combined.

llvm-svn: 295341

SHF_LINK_ORDER sections adds special ordering requirements.
Such sections references other sections. Previously we would crash
if section that other were referenced to was discarded by script.

Patch fixes that by discarding all dependent sections in that case.
It supports chained dependencies, testcase is provided.

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

llvm-svn: 295332

Unfortunately, the common way of writing linker scripts seems to be
to get the output of ld.bfd --verbose and edit it a bit.

Also unfortunately, the bfd default script contains things like

.rela.dyn : { *(... .rela.data ...) }

but bfd actually ignores that for -emit-relocs, so we have to do the
same.

llvm-svn: 295324

The code to handle the input SHT_REL/SHT_RELA sections was getting
confused with the linker generated relocation sections.

llvm-svn: 295322

That fixes a case when section has more than one metadata 
section. Previously GC would collect one of such sections 
because we had implementation that stored only last one as
dependent.

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

llvm-svn: 295298

llvm-svn: 295289

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