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 were looking up sections by name during expression evaluation. By
keeping track of forward declarations we can do the lookup during
script parsing.

Doing the lookup earlier will be more efficient when assignAddresses
is run twice and removes two uses of OutputSections.

llvm-svn: 304381

The sections are ordered, so we can just use the first one when
looking for the lowest address.

llvm-svn: 304369

llvm-svn: 304368

Another step into merging the linker script and non linker script code
paths.

llvm-svn: 304339

Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.

This was brittle and caused bugs like the one fixed by r304260.

We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.

llvm-svn: 304338

llvm-svn: 304334

llvm-svn: 304330

llvm-svn: 304328

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 change converts the writing of the .ARM.exidx sentinel section to use
the InputSectionDescriptions instead of OutputSection::Sections this is in
preparation for the retirement of OutputSection::Sections.
    
Differential Revision: https://reviews.llvm.org/D33500

llvm-svn: 304289

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

By the time we get here all live sections should have been combined
into InputSections.

llvm-svn: 304243

llvm-svn: 304240

    
When there is a linker script with .ARM.exidx in the SECTIONS
command we must add the .ARM.exidx sentinel section to the
InputSectionDescriptions as well as to OutputSection::Sections.

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

llvm-svn: 304206

llvm-svn: 304197

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

llvm-svn: 304182

Now that we are trying to use the linker script representation as the
canonycal one, there are a few loops looking for just OutputSectionCommands.

Create a vector with just the OutputSectionCommands once that is
stable to simplify the rest of the code.

llvm-svn: 304181

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

http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/8549/steps/build_Lld/logs/stdio

llvm-svn: 304016

After fabricateDefaultCommands we can look at the script commands.

llvm-svn: 304014

This is a necessary step for moving clearOutputSections earlier.

llvm-svn: 304009

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

Restore bitwise-or order and fix warning
(was changed by mistake during resolve of conflicts).

llvm-svn: 303976

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

https://sourceware.org/gdb/onlinedocs/gdb/Index-Section-Format.html says:
"A CU vector in the constant pool is a sequence of offset_type values. 
The first value is the number of CU indices in the vector. 
Each subsequent value is the index and symbol attributes of a CU in the CU list."

Previously we keeped 2 values until the end, what was useless. 
Initially was a part of D32647, though it is possible to split out. 
Patch do that.

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

llvm-svn: 303973

llvm-svn: 303961

llvm-svn: 303959

llvm-svn: 303958

llvm-svn: 303948

In this way, the content and the flag is always consistent, which I
think better than removing the bit when input sections reaches the Writer.

llvm-svn: 303926

This reverts commit r303787.

It caused a slowdown in fast links. That is, links with no debug info
or optimizations.

llvm-svn: 303925

llvm-svn: 303905

It is not clear why a synthetic section wants to use padding defined
in the linker script. The padding is for the space between sections.

It was also missing a test.

llvm-svn: 303812

This is the only place we use threads for ICF. The intention of this code
was to split an input vector into 256 shards and process them in parallel.
What the code was actually doing was to split an input into 257 shards,
process the first 256 shards in parallel, and the remaining one in serial.

That means this code takes ceil(256/n)+1 instead of ceil(256/n) where n
is the number of available CPU cores. The former converges to 2 while
the latter converges to 1.

This patches fixes the above issue.

llvm-svn: 303797