On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..

If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.

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

llvm-svn: 306282

Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.

This pathc saves the original symbol name and restore it after memcpy
to keep the original name.

This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.

llvm-svn: 306036

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

llvm-svn: 305983

This is unnecessary because --gc-sections runs before ICF.

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

llvm-svn: 305954

The --exclude-libs option is not a popular option, but at least some
programs in Android depend on it, so it's worth to support it.

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

llvm-svn: 305920

llvm-svn: 305877

The option numbers in the macro were off by one which
leads to some confusion.  There are actually 12 arguments
to this macro.

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

llvm-svn: 305823

This is patch for GSoC project, bash-completion for clang.

To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.

In this patch, Options.td was mainly changed in order to add value class
in Options.inc.

llvm-svn: 305805

I found this while trying to build u-boot. It uses -Ttext in
combination with linker scripts.

My first reaction was to change the linker scripts to have the correct
value, but I found that it is actually quite convenient to have -Ttext
take precedence.

By having just

.text : { *(.text) }

In the script, they can define the text address in a single Makefile
and pass it to ld with -Ttext and for the C code with
-DFoo=value. Doing the same with linker scripts would require them to
be generated during the build.

llvm-svn: 305766

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

llvm-svn: 305742

This patch adds support for segment NONE in linker scripts which enables the
specification that a section should not be assigned to any segment.

Note that GNU ld does not disallow the definition of a segment named NONE, which
if defined, effectively overrides the behaviour described above. This feature
has been copied.

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

llvm-svn: 305700

In r305364, Rui changed the mechanism that parses -z option values slightly.
This caused a bug, as demonstrated by this test, which now fails:

---
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t -z max-page-size

.global _start
_start:
  nop
---

Before, the link succeeded and set the max-page-size to the target default.

After we get the following two error messages:
"invalid max-page-size: "
"max-page-size: value isn't a power of 2"

The latter error is because an uninitialised variable ends up being passed back
to getMaxPageSize).

This change ensures we only get the first error.

Reviewers: ruiu

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

llvm-svn: 305679

    
The get{ARM,AArch64}UndefinedRelativeWeakVA() functions should only be
called for PC-relative relocations. Complete the supported pc-relative
relocations in the switch statement and make the default case unreachable.

The R_ARM_TARGET relocation can be evaluated as R_ARM_REL32 but it is only
used in the context of exception tables, and is never output with respect
to a weak reference so it does not appear in the switch statement.
    
Differential Revision: https://reviews.llvm.org/D34138

llvm-svn: 305673

We would crash before.

llvm-svn: 305615

We would crash instead before.

llvm-svn: 305614

We would crash instead before.

llvm-svn: 305613

llvm-svn: 305601

llvm-svn: 305577

AVR support is somewhat exotic as generated ELF executables are not
directly consumed but objcopy'ed to write it to on-chip flush memory.
This comment describes it for those why a full-fledged ELF linker is
used to link programs for the 8-bit microcontroller.

llvm-svn: 305567

Target.cpp contains code for all the targets that LLD supports. It was
simple and easy, but as the number of supported targets increased,
it got messy.

This patch splits the file into per-target files under ELF/arch directory.

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

llvm-svn: 305565

    
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