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

llvm-svn: 301982

llvm-svn: 301979

llvm-svn: 301975

This reverts commit r301964. It broke the build.

llvm-svn: 301969

llvm-svn: 301964

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

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

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

readelf's output is much easier to read than objdump's as you can see below.

  $ readelf --string-dump .comment foo
  String dump of section '.comment':
    [     1]  GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
    [    2c]  clang version 5.0.0
    [    41]  Linker: LLD 5.0.0

  $ objdump -j .comment -s foo
  Contents of section .comment:
   0000 00474343 3a202855 62756e74 7520342e  .GCC: (Ubuntu 4.
   0010 382e342d 32756275 6e747531 7e31342e  8.4-2ubuntu1~14.
   0020 30342e33 2920342e 382e3400 636c616e  04.3) 4.8.4.clan
   0030 67207665 7273696f 6e20352e 302e3020  g version 5.0.0
   0040 004c696e 6b65723a 204c4c44 20352e30  .Linker: LLD 5.0
   0050 2e3000                               .0.

llvm-svn: 301515

llvm-svn: 301514

llvm-svn: 301513

SoName's type has changed from StringRef to std::string, so this
code does not make sense anymore.

llvm-svn: 301490

This patch is to reduce amount of template uses. The new code is less
exciting and boring than before, but I think it is easier to read.

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

llvm-svn: 301488

We were already pretty close, the one exception was when a name was
reused in another SECTIONS directive:

SECTIONS {
  .text : { *(.text) }
  .data : { *(.data) }
}
SECTIONS {
  .data : { *(other) }
}

In this case we would create a single .data and magically output
"other" while looking at the first OutputSectionCommand.

We now create two .data sections. This matches what gold does. If we
really want to create a single one, we should change the parser so that
the above is parsed as if the user had written

SECTIONS {
  .text : { *(.text) }
  .data : { *(.data) *(other)}
}

That is, there should be only one OutputSectionCommand for .data and
it would have two InputSectionDescriptions.

By itself this patch makes the code a bit more complicated, but is an
important step in allowing assignAddresses to operate just on the
linker script.

llvm-svn: 301484