In preparation for supporting range extension thunks we now continually
call createThunks() until no more thunks are added. This requires us to
record the thunks we add on each pass and only merge the new ones into the
OutputSection. We also need to check if a Relocation is targeting a thunk
to prevent us from infinitely creating more thunks.
    
Differential Revision: https://reviews.llvm.org/D34034

llvm-svn: 305555

llvm-svn: 305514

This is probably the main patch left in unifying our intermediary
representation.

It moves the creation of default commands before section sorting. This
has the nice effect that we now have one location where we decide
where an orphan section should be placed.

Before this patch sortSections would decide the relative location of
orphan sections to other sections, but it was up to placeOrphanSection
to decide on the exact location.

We now only sort sections we created since the linker script is
already in the correct order.

llvm-svn: 305512

This is necessary to ensure that sections containing symbols referenced
from linker scripts (e.g. in data commands) don't get GC'd.

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

llvm-svn: 305452

Reviewers: ruiu, rafael, grimar, atanasyan, psmith, dylanmckay

Reviewed By: ruiu, rafael, grimar, dylanmckay

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

llvm-svn: 305444

I added the same function in llvm, so this is causing an
ambiguous symbol.

llvm-svn: 305412

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

llvm-svn: 305375

Summary: I found that getString defined in the LLD's Driver.cpp is
exactly the same as Arg::getLastArgValue defined in
llvm/Option/ArgLIst.h. This patch removes that local function and use
the function that the Arg class provides.

Reviewers: ruiu

Subscribers: emaste, llvm-commits

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

llvm-svn: 305374

Summary: Pointed out by Yuka Takahashi.

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

llvm-svn: 305364

llvm-svn: 305341

This is similar to what we do for InputSections and makes them easier
to access.

llvm-svn: 305337

llvm-svn: 305333

Currently we do layout as if non alloc sections had an actual address
and then set it to zero. This produces a few odd results where a
symbol has an address that is inconsistent with the section address.

The simplest way to fix it is probably to just set the address earlier.

The behavior of bfd seems to be similar, but it only sets the non
alloc section address is missing from the linker script or if the
script has an explicit " : 0" setting the address of the output
section (which the default script does).

llvm-svn: 305323

The ELF standard defines that the SHT_GROUP section as follows:

 - its sh_link has the symbol index, and
 - the symbol name is used to uniquify section groups.

Object files created by GNU gold does not seem to comply with the
standard. They have this additional rule:

 - if the symbol has no name and a STT_SECTION symbol, a section
   name is used instead of a symbol name.

If we don't do anything for this, the linker fails with a mysterious
error message if input files are generated by gas. It is unfortunate
but I think we need to support it.

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

llvm-svn: 305218

Given

.weak target
 .global _start
_start:
 b target

The intention is that the branch goes to the instruction after the
branch, effectively turning it on a nop.  The branch adds the runtime
PC, but we were adding it statically too.

I noticed the oddity by inspection, but llvm-objdump seems to agree,
since it now prints things like:

b       #-4 <_start+0x4>

llvm-svn: 305212

Relocations referring to merge sections are considered equal if they
resolve to the same offset in the same output section.

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

llvm-svn: 305177

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

llvm-svn: 305176

llvm-svn: 305156

Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).

If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.

What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).

Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too.  An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070

This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.

bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html

llvm-svn: 305135

SHF_GROUP bit doesn't make sense in executables or DSOs, so linkers are
expected to remove that bit from section flags. We did that when we create
output sections.

This patch is to do that earlier than before. Now the flag is dropped when
we instantiate input section objects.

This change improves ICF. Previously, two sections that differ only in
SHF_GROUP flag were not merged, because when the control reached ICF,
the flag was still there. Now the flag is dropped before reaching to ICF,
so the difference is ignored naturally.

This issue was found by pcc.

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

llvm-svn: 305134

llvm-svn: 305112

This is used by linux kernel build system.

(https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt "3.2 Built-in object goals")

It has for example next configuration for linking built-in.o files:
drivers-y	:= $(patsubst %/, %/built-in.o, $(drivers-y))
drivers-$(CONFIG_PCI)		+= arch/ia64/pci/
...
drivers-$(CONFIG_OPROFILE)	+= arch/ia64/oprofile/

Im most simple case all CONFIG_* options are off. That means linker is called with empty input archive, 
emulation option and no inputs and expected to generate some relocatable output. 
ld.bfd is able to do that, we dont.

Patch allows to support this case.

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

llvm-svn: 305069

The symbols generated for Thunks have type STT_FUNC, to permit a thunk to
be reused via a blx instruction the Thumb bit (0) needs to be set properly.

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

llvm-svn: 305065

SyntheticSections.cpp:1773:29: error: chosen constructor is explicit in copy-initialization
        CuVectors.push_back({});
                            ^~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/set:428:14: note: constructor declared here
    explicit set(const value_compare& __comp = value_compare())
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:702:59: note: passing argument to parameter '__x' here
    _LIBCPP_INLINE_VISIBILITY void push_back(value_type&& __x);

llvm-svn: 305054

llvm-svn: 305048

llvm-svn: 305047

llvm-svn: 305010

Previously, it couldn't parse

  SECTIONS .text (0x1000) : { *(.text) }

because "(" was interpreted as the begining of the "(NOLOAD)" directive.

llvm-svn: 305006

This then requires delaying a call to getHeaderSize.

llvm-svn: 304961

This allows moving clearOutputSections earlier.

llvm-svn: 304952

The real offsets are computed in assignAddresses and we compute the
special cases we need earlier after this.

llvm-svn: 304950

llvm-svn: 304948

This allows moving clearOutputSections a bit earlier.

llvm-svn: 304947

Without this, when building with shared BUILD_SHARED_LIBS=ON
I get errors such as:

lib/Core/Reader.cpp:40: error: undefined reference to
'llvm::identify_magic(llvm::StringRef)'

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

llvm-svn: 304932

This patch reimplements .gdb_index in more natural way,
that makes proccess of switching to multithreaded index building to
be trivial. 

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

llvm-svn: 304927

This is PR32351

Each output section may have a type. The type is a keyword in parentheses.
(https://sourceware.org/binutils/docs/ld/Output-Section-Type.html#Output-Section-Type)
This patch support only one type, it is NOLOAD.
If output section has such type, we force it to be SHT_NOBITS. 

More details are available on a review page.

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

llvm-svn: 304925

llvm-svn: 304914

Approach significantly simplifies LLD .gdb_index code and makes it much faster.
Also it should resolve issues, like D33176 tries to address once and forever in a clean way.

LLC binary linking without patch and without --gdb-index: 1,599241063
LLC binary linking without patch and with --gdb-index: 6,064316262
LLC binary linking with patch and with --gdb-index: 4,116792104

Time spent for building gdbindex changes from (6,064316262 - 1,599241063 == 4,465075199)
to (4,116792104- 1,599241063 == 2,517551041).
That is 2,517551041/4,465075199 = 0,564 or about 44% speedup.

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

llvm-svn: 304895

Thunks are now generated per InputSectionDescription instead of per
OutputSection. This allows created ThunkSections to be inserted directly
into InputSectionDescription.

Changes in this patch:
- Loop over InputSectionDescriptions to find relocations to Thunks
- Generate a ThunkSection per InputSectionDescription
- Remove synchronize() as we no longer need it
- Move fabricateDefaultCommands() before createThunks

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

llvm-svn: 304887

Previously we would merge relocation sections by name.
That did not work in some cases, like testcase shows.

Patch implements logic to merge relocation sections if their target
sections were merged into the same output section.

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

llvm-svn: 304886