It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.

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

llvm-svn: 302083

It doesn't matter what binding we store in a non-UsedInRegularObj undefined
symbol because we should reset it when we see a real undefined symbol in
a combined LTO object. The fact that we weren't doing so before is a bug
(PR32899) which is now fixed.

llvm-svn: 302067

We were ignoring strong undefined symbols if they followed weak ones.

Fixes pr32899.

llvm-svn: 302065

The --section-start <name>=<address> needs to be translated into equivalent
linker script commands. There are a couple of problems with the existing
implementation:
- The --section-start with the lowest address is assumed to be at the start
of the map. This assumption is incorrect, we have to iterate through the
SectionStartMap to find the lowest address.
- The addresses in --section-start were being over-aligned when the
sections were marked as PageAlign. This is inconsistent with the use of
SectionStartMap in fixHeaders(), and can cause problems when the PageAlign
causes an "unable to move location counter backward" error when the
--section-start with PageAlign is aligned to an address higher than the next
--section-start. The ld.bfd and ld.gold seem to be more consistent with this
approach but this is not a well specified area.
    
This change fixes the problems above and also corrects a typo in which
fabricateDefaultCommands() is called with the wrong parameter, it should be
called with AllocateHeader not Config->MaxPageSize.

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

llvm-svn: 302007

Before rL301170 was landed, LLD did not produce correct entries in .gdb_index address area.
Issue was fixed on LLVM DWARF parsers side and was relative to how .debug_ranges
section was scanned. It was main problem of PR32319.

It makes sense to have testcase on LLD size too. This checks that we generate proper values 
now, because we do not have any tests for .gdb_index which works with .debug_ranges atm.

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

llvm-svn: 302006

llvm-svn: 301982

llvm-svn: 301979

llvm-svn: 301975

This reverts commit r301964. It broke the build.

llvm-svn: 301969

llvm-svn: 301964

With the forthcoming codeview::StringTable which a pdb::StringTable
would hold an instance of as one member, this ambiguity becomes
confusing.  Rename to PDBStringTable to avoid this.

llvm-svn: 301948

Strip on OpenBSD does not correctly handle an empty .eh_frame section
and produces broken binaries in that case. Currently lld creates such
an empty .eh_frame section, despite the fact that the OpenBSD crtend.o
explicitly inserts a terminator. The Linux LSB "standard":

https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME

explicitly says that

    The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records.

This diff includes a test that specifically tests the issue I'm seeing
on OpenBSD.

Patch by Mark Kettenis!

llvm-svn: 301931

If there is a bug in the LTO implementation that causes it to fail to provide
an expected symbol definition, the linker should report an undefined symbol
error. Unfortunately, we were failing to do so if the symbol definition
was weak, as the undefine() function was turning the definition into a weak
undefined symbol, which resolves to zero if the symbol remains undefined. This
patch causes us to set the binding to STB_GLOBAL when we undefine a symbol.

I can't see a good way to test this. The behaviour should only be observable
if there is a bug in the LTO implementation.

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

llvm-svn: 301897

llvm-svn: 301896

It didn't have to be a member function of Driver. This patch makes
that function a file-scoped non-member function.

llvm-svn: 301895

Also factored out code.

llvm-svn: 301833

When using linkerscripts we were trying to sort SHF_LINK_ORDER
sections too early. Instead of always doing two runs of
assignAddresses, record the section order in processCommands.

llvm-svn: 301830

Leaving a directory with a permission 0o100 is inconvenient.
For example, macOS's rm can't remove such directory.

llvm-svn: 301821

llvm-svn: 301778

When the -no-keep-memory option is given, BFD linker tries to save
memory in their own way. Since our internal architecture is completely
different from that linker, that option doesn't make sense to us.

llvm-svn: 301772

llvm-svn: 301771

For an option -foo-bar-baz, we have Config->FooBarBaz. Since -rpath is
-rpath and not -r-path, it should be Config->Rpath instead Config->RPath.

llvm-svn: 301759

llvm-svn: 301758

llvm-svn: 301757

llvm-svn: 301754

This version uses a set to speed up the synchronize method.

Original message:

    Remove LinkerScript::flush.

    This patch replaces flush with a last ditch attempt at synchronizing
    the section list with the linker script "AST".

    The synchronization is a bit of a hack and should in time be avoided
    by creating the AST earlier so that modifications can be made directly
    to it instead of modifying the section list and synchronizing it back.

    This is the main step for fixing
    https://bugs.llvm.org/show_bug.cgi?id=32816. With this in place I
    think the only missing thing would be to have processCommands assign
    section indexes as dummy offsets so that the sort in
    OutputSection::finalize works.

    With this LinkerScript::assignAddresses becomes much simpler, which
    should help with the thunk work.

llvm-svn: 301745

Fixes PR32785. Thanks to Piotr Padlewski for the report and
Rafael for the fix.

llvm-svn: 301729

Since the output format has been simplified, the class to print
out a map file doesn't seem to be needed anymore. We can replace
it with a few non-member functions.

llvm-svn: 301715

This patch is to ignore .debug_gnu_pub{names,types} sections if the
-gdb-index option was given.

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

llvm-svn: 301710

This reverts commit r301678 since that change significantly slowed
down the linker. Before this patch, LLD could link clang in 8 seconds,
but with this patch it took 40 seconds.

llvm-svn: 301709

This change was motivated by output from lld-link.exe and link.exe
getting intermixed. There's already a flush() call in message(), so
there's precedence.

llvm-svn: 301693

llvm-svn: 301691

Previously, we printed out input sections and input files in
separate columns as shown below.

  Address          Size             Align Out     In      File    Symbol
  0000000000201000 0000000000000015     4 .text
  0000000000201000 000000000000000e     4         .text
  0000000000201000 000000000000000e     4                 foo.o
  0000000000201000 0000000000000000     0                         _start
  0000000000201005 0000000000000000     0                         f(int)
  000000000020100e 0000000000000000     0                         local
  0000000000201010 0000000000000002     4                 bar.o
  0000000000201010 0000000000000000     0                         foo
  0000000000201011 0000000000000000     0                         bar

This format doesn't make much sense because for each input section,
there's always exactly one input file. This patch changes the format
to this.

  Address          Size             Align Out     In      Symbol
  0000000000201000 0000000000000015     4 .text
  0000000000201000 000000000000000e     4         foo.o:(.text)
  0000000000201000 0000000000000000     0                 _start
  0000000000201005 0000000000000000     0                 f(int)
  000000000020100e 0000000000000000     0                 local
  0000000000201010 0000000000000002     4         bar.o:(.text)
  0000000000201010 0000000000000000     0                 foo
  0000000000201011 0000000000000000     0                 bar

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

llvm-svn: 301683

This patch replaces flush with a last ditch attempt at synchronizing
the section list with the linker script "AST".

The synchronization is a bit of a hack and should in time be avoided
by creating the AST earlier so that modifications can be made directly
to it instead of modifying the section list and synchronizing it back.

This is the main step for fixing
https://bugs.llvm.org/show_bug.cgi?id=32816. With this in place I
think the only missing thing would be to have processCommands assign
section indexes as dummy offsets so that the sort in
OutputSection::finalize works.

With this LinkerScript::assignAddresses becomes much simpler, which
should help with the thunk work.

llvm-svn: 301678

llvm-svn: 301674

If a string is shorter than 7 characters, we used to print out
trailing whitespace characters.

llvm-svn: 301668

llvm-svn: 301661

We found that some part of code for the -Map option takes O(m*n)
where m is the number of input sections in some file and n is
the number of symbols in the same file. If you do LTO, we usually
have only a few object files as inputs for the -Map option
feature, so this performance characteristic was worse than I
expected.

This patch rewrites the -Map option feature to speed it up.
I eliminated the O(m*n) bottleneck and also used multi-threading.

As a result, clang link time with the -Map option improved from
18.7 seconds to 11.2 seconds. Without -Map, it takes 7.7 seconds,
so the -Map option is now about 3x faster than before for this
test case (from 11.0 seconds to 3.5 seconds.) The generated output
file size was 223 MiB, and the file contains 1.2M lines.

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

llvm-svn: 301659

CONSTANT imports expect both the `_imp_` prefixed and non-prefixed
symbols should be added to the symbol table.  This allows for linking
symbols like _NSConcreteGlobalBlock in WinObjC.  The previous change
would generate the import library properly by handling the option but
would not consume the generated entry properly.

llvm-svn: 301657

This seems to be the behavior of the MSVC linker. Previously, this
incompatibility caused nasty issues in chromium build a few times.

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

llvm-svn: 301598