Spec says: (http://www.sco.com/developers/gabi/latest/ch4.sheader.html)

sh_info
This member holds extra information, whose interpretation depends on the section type.
If the sh_flags field for this section header includes the attribute SHF_INFO_LINK, 
then this member represents a section header table index.

SHF_INFO_LINK
The sh_info field of this section header holds a section header table index.

Since sh_info for SHT_REL[A] sections should contain the section header index of the
section to which the relocation applies, this is
consistent with spec to put this flag. Behavior matches both bfd and gold as well.

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

llvm-svn: 304531

This is PR33243. R_GOTONLY_PC_FROM_END was not in a list of link time constant
expressions and that was a result of confusiing messages like PR shows:

/usr/bin/ld.lld: error: /usr/lib/go/src/runtime/alg.go:47: 
can't create dynamic relocation R_386_GOTPC against local symbol in readonly segment defined in /tmp/nice/go-link-597453838/go.o

Though in reality we just should not have try to create a dynamic relocation for this case at all.

Patch fixes the issue.

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

llvm-svn: 304393

This is PR33239, previously we segfault on given testcase.

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

llvm-svn: 304392

We would crash if a SHF_LINK_ORDER section pointed to a non
InputSection section. Since those sections are not merged in order,
SHF_LINK_ORDER is pretty meaningless and we can error on that case.

llvm-svn: 304327

This happens when attempting to link shared libraries using exceptions on
MIPS. It requires -z notext because clang generates R_MIPS_64 relocations
inside .eh_frame.
The crash happened because for EhInputSection the OutSec member is null.

Patch by Alexander Richardson!

llvm-svn: 304260

I found that during visual inspection of code while wrote different patch.
Script in testcase probably have nothing common with real life, but
we segfault currently using it.

If output section is known NOBITS, there is no need to create
writers threads for doing nothing or proccess any filler logic that 
is useless here. We can just early return, that is what this patch do.

DIfferential revision: https://reviews.llvm.org/D33646

llvm-svn: 304192

InputSections may contain MergeInputSection members which trigger
a segmentation fault when trying to cast them to InputSection.

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

llvm-svn: 304189

While the following expression is handled fine:

  PROVIDE_HIDDEN(newsym = oldsym + address);

The following expression triggers an error because the expression
is evaluated as absolute:

  PROVIDE_HIDDEN(newsym = ALIGN(oldsym, CONSTANT(MAXPAGESIZE)) + address);

To avoid this error, we use late evaluation for ALIGN by making the
alignment an attribute of the expression itself.

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

llvm-svn: 304185

This is PR33052, "Bug 33052 - -r eats comdats ".

To fix it I stop removing group section from out when -r is given
and fixing SHT_GROUP content when writing it just like we do some
other fixup, e.g. for Rel[a]. (it needs fix for section indices that
are in group).

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

llvm-svn: 304140

The .dynamic section of an ELF almost doesn't need to be written to with
the exception of the DT_DEBUG entry. For several reasons having a read
only .dynamic section would be useful. This change adds the -z keyword
"rodynamic" which forces .dynamic to be read-only. In this case DT_DEBUG
will not be emited.

Patch by Jake Ehrlich

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

llvm-svn: 304024

On SPARC, .plt is both writeable and executable. The current way
sections are sorted means that lld puts it after .data/.bss. but it
really needs to be close to .test to make sure branches into .plt
don't overflow. I'd argue that because .bss is supposed to come last
on all architectures, we should change the default sort order such
that writable and executable sections come before sections that are
just writeable. read-only executable sections should still come after
sections that are just read-only of course. This diff makes this
change.

llvm-svn: 304008

I found this when builded llc binary using gcc 5.4.1 + LLD.
gcc produces duplicate entries in .debug_gnu_pubtypes section, ex:

UnifyFunctionExitNodes.cpp.o has:
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"

clang produces single entry here:
0x0000d291 EXTERNAL TYPE "std::__success_type<void *>"

If we link output from gcc with LLD, that would produce excessive duplicate
entries in .gdb_index constant pool area. That does not seem affect gdb work,
but makes .gdb_index larger than it can be.

I also checked that gold filters out such duplicates too. Patch fixes it.

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

llvm-svn: 303975

llvm-svn: 303905

Fix for PR33029.

llvm-svn: 303770

If the compiler driver passes --build-id and the user uses -Wl to
pass --build-id= then the user's flag should take precedence.

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

llvm-svn: 303689

Fix for PR33096.

llvm-svn: 303579

This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.

The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.

The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.

Fixes PR32924

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

llvm-svn: 303337

They are too slow otherwise. We track the issue in pr32942.

llvm-svn: 303097

We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.

This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.

A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.

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

llvm-svn: 303089

Fixes PR33032.

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

llvm-svn: 303088

We used to place orphans by just using compareSectionsNonScript.

Then we noticed that since linker scripts can use another order, we
should first try match the section to a given PT_LOAD. But there is
nothing special about PT_LOAD. The same issue can show up for
PT_GNU_RELRO for example.

In general, we have to search for the most similar section and put the
orphan next to it. Most similar being defined as how long they follow
the same code path in compareSecitonsNonScript.

That is what this patch does. We now compute a rank for each output
section, with a bit for each branch in what was
compareSectionsNonScript.

With this findOrphanPos is now fully general and orphan placement can
be optimized by placing every section with the same rank at once.

The included testcase is a variation of many-sections.s that uses
allocatable sections to avoid the fast path in the existing
code. Without threads it goes form 46 seconds to 0.9 seconds.

llvm-svn: 302903

This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."

Because DF_STATIC_TLS does not look to be used by glibc or anything else.

llvm-svn: 302884

Both gold and bfd restrict that one:

ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be 
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var

What looks reasonable because it is 32 bit one. Patch do the same.

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

llvm-svn: 302881

Testcase itself depends on .text section location, which was orphan earlier.

Suggested by Rafael Espíndola

llvm-svn: 302792

This improves many-sections.s with a linker script from 22s to 0.9s.

llvm-svn: 302708

Previously we were not printing out the type of the incompatible section
which made it difficult to determine what the problem was.

The error message format has been change to the following:

  error: section type mismatch for .shstrtab
  >>> <internal>:(.shstrtab): SHT_STRTAB
  >>> output section .shstrtab: Unknown

Patch by Alexander Richardson.

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

llvm-svn: 302694

This behavior differs from the semantics implemented by GNU linkers
which only define this symbol iff ELF headers are in the memory
mapped segment.

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

llvm-svn: 302687

This is PR32664.

Issue was revealed by linux kernel script which was:

SECTIONS {
 . = (0xffffffff80000000 + ALIGN(0x1000000, 0x200000));
 phys_startup_64 = ABSOLUTE(startup_64 - 0xffffffff80000000);

 .text : AT(ADDR(.text) - 0xffffffff80000000) {
.....
  *(.head.text)
Where startup_64 is in .head.text.

At the place of assignment to phys_startup_64 we can not calculate absolute value for startup_64
because .text section has no VA assigned. Two patches were prepared earlier to address this: D32173 and D32174.

And in comments for D32173 was suggested not try to support this case, but error out.

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

llvm-svn: 302668

Adds support for the ORIGIN and LENGTH linker script built in functions.

  ORIGIN(memory) Return the origin of the memory region
  LENGTH(memory) Return the length of the memory region

Redo of D29775 for refactored linker script parsing.

Patch by Robert Clarke

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

llvm-svn: 302564

This is PR32437.

DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the 
dynamic linker to reject attempts to load this file dynamically. 
It indicates that the shared object or executable contains code 
using a static thread-local storage scheme. Implementations need 
not support any form of thread-local storage.

Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.

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

llvm-svn: 302414

Previously it was impossible to use linkerscript with --compress-debug-sections 
because of assert failture:
Assertion failed: isFinalized(), file C:\llvm\lib\MC\StringTableBuilder.cpp, line 64

Patch fixes the issue

llvm-svn: 302413

LazyObjectFile might turn out to be a BitcodeFile, so we need
OffsetInArchive.

llvm-svn: 302242

The test ELF/lto/thin-archivecollision.ll was not testing what it
wanted to test. It needs two archive members with the same name, but
different offsets.

Without this we could remove all references of OffsetInArchive and all
tests would still pass.

Fixing the test showed that the --whole-archive case was broken, which
this patch fixes.

llvm-svn: 302241

It is needed for creating an unique identifier for ThinLTO.

This fixes pr32931.

llvm-svn: 302235

Previously we accepted --defsym=foo=value only.

Reported by Sean Silva.

llvm-svn: 302227

We were correctly computing the size contribution of a .tbss input
section (it is none), but we were incorrectly considering the
alignment of the output section: it was advancing Dot instead of
ThreadBssOffset.

As far as I can tell this was always wrong in our linkerscript
implementation, but that became more visible now that the code is
shared with the non linker script case.

llvm-svn: 302107

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

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