Some tools (dwarfdump for example) get confused by the current -O0 -r
output since it has multiple copies of .debug_str.

We cannot just merge sections with the same name as they can have
different sh_entsize.

We could have duplicated logic for merging sections based on name and
sh_entsize, but it seems better to just use the existing logic by
enabling optimizations.

llvm-svn: 328640

llvm-svn: 328605

llvm-svn: 328604

SharedFile::parseRest function grew organically and got a bit hard to
understand. This patch refactor it. This patch also adds comments.

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

llvm-svn: 328579

Previously, we used 0 as an alias for VER_NDX_GLOBAL and had a dummy
entry in SharedFile::Verdefs so that the access to the array is within
its boundary. But that's not straightforwad. We can just stop doing both.

llvm-svn: 328401

A bug in BFD linker is not our FIXME item.

llvm-svn: 328381

llvm-svn: 328285

With this patch lld will iterate over compile units to find the line
tables instead of assuming there is only one at offset 0.

llvm-svn: 328284

This is more readable and should reduce the noise in a followup patch.

llvm-svn: 328164

llvm-svn: 327645

llvm-svn: 327280

Our code assumes all input sections in an output SHF_LINK_ORDER
section has SHF_LINK_ORDER flag. We do not check that and that can cause a crash.

That happens because we call 
std::stable_sort(Sections.begin(), Sections.end(), compareByFilePosition);, 
where compareByFilePosition predicate does not expect to see
null when calls getLinkOrderDep. 

The same might happen when sections refer to non-regular sections. 
Test cases demonstrate the issues, patch fixes them.

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

llvm-svn: 327006

We don't need to handle an object file having more than one symbol table,
so as soon as we find the first one, we can process it and then return
from the function.

llvm-svn: 326977

addElfSymbols and readJustSymbolsFile still has duplicate code, but
I didn't come up with a good idea to eliminate them. Since this patch
is an improvement, I'm sending this for review.

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

llvm-svn: 326972

LLD uses the debug info and debug line sections to determine the location of
e.g. references to undefined symbols, when producing error messages. In the
event that debug info was present, but debug line parsing failed for some
reason, then a nullptr would end up being dereferenced by the location-lookup
code.

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

Reviewers: grimar
llvm-svn: 326899

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

llvm-svn: 326835

With the recent fixes these symbols have more in common than not with
regular undefined symbols.

llvm-svn: 326242

It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.

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

llvm-svn: 326176

There seems to be no reason to collect this list of symbols.

Also fix a bug where --exclude-libs would apply to all symbols that
appear in an archive's symbol table, even if the relevant archive
member was not added to the link.

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

llvm-svn: 325380

MIPS BFD linker puts _gp_disp symbol into DSO files and assigns zero
version definition index to it. This value means 'unversioned local
symbol' while _gp_disp is a section global symbol. We have to handle
this bug in the LLD because BFD linker is used for building MIPS
toolchain libraries.

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

llvm-svn: 324467

We did not report valid filename for duplicate symbol error when
symbol came from binary input file.
Patch fixes it.

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

llvm-svn: 324217

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

llvm-svn: 324146

r323476 added support for DW_FORM_line_strp, and incorrectly made that
depend on having a DWARFUnit available.  We shouldn't be tracking
.debug_line_str in DWARFUnit after all.  After this patch, I can do an
NFC follow up and undo a bunch of the "plumbing" part of r323476.

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

llvm-svn: 323691

We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.

It is only executed when there is an error and it allows detemplating
a lot of code.

llvm-svn: 321404

This simplifies toRegularSection and reduces the noise in a followup
patch.

llvm-svn: 321240

We use null files in sections to represent linker created sections,
so ObjFile<ELFT> is never null.

llvm-svn: 321238

llvm-svn: 321216

llvm-svn: 321194

Every shared symbol has a file, so we can use a reference.

llvm-svn: 321187

llvm-svn: 321186

llvm-svn: 321185

I noticed that the continue this patch deletes was not tested. Trying
to add a test I realized that we never put a VER_NDX_LOCAL symbol in
the dynamic symbol table. There doesn't seem to be any reason for a
linker to use VER_NDX_LOCAL for a defined shared symbol.

llvm-svn: 320817

llvm-svn: 320772

Specifically, libwidevinecdm.so in Chrome has such bad symbol.
It seems the BFD linker handles them as local symbols, so instead
of inserting them to the symbol table, we should skip them too.

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

llvm-svn: 320770

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

llvm-svn: 320652

This runs before ICF, so Sec->Repl == Sec.

llvm-svn: 320543

By using an index instead of a pointer for verdef we can put the index
next to the alignment field. This uses the otherwise wasted area and
reduces the shared symbol size.

By itself the performance change of this is in the noise, but I have a
followup patch to remove another 8 bytes that improves performance
when combined with this.

llvm-svn: 320449

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

llvm-svn: 320005

This patch is to rename check CHECK and make it a C macro, so that
we can evaluate the second argument lazily.

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

llvm-svn: 319974

This brings memory allocations when linking clang from 270.96MB to
267.80MB.

llvm-svn: 319932