Found that during attempts of linking linux kernel,
previously we partially duplicated code from getOutputSection(),
and it missed commons symbol case.

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

llvm-svn: 292594

If two sections contained relocations to absolute symbols with the same
value we would crash when trying to access their sections. Add a check that
both symbols point to sections before accessing their sections, and treat
absolute symbols as equal if their values are equal.

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

llvm-svn: 292578

I don't know of anything using it, but we should handle it like _end.

llvm-svn: 292513

The freebsd sbrk implementation uses _end to find the initial value of
brk, so it has to be defined in the main binary.

This should fix the emacs build.

llvm-svn: 292512

    
A necessary first step towards range extension thunks is to delay
the creation of thunks until the layout of InputSections within
OutputSections has been done.
    
The change scans the relocations directly from InputSections rather
than looking in the ELF File the InputSection came from. This will
allow a future change to redirect the relocations to symbols defined
by Thunks rather than indirect when resolving relocations.
    
A side-effect of moving ThunkCreation is that the OutSecOff of
InputSections may change in an OutputSection that contains Thunks.
In well behaved programs thunks are not in OutputSections with
dynamic relocations.
    
Differential Revision: https://reviews.llvm.org/D28811

llvm-svn: 292359

This patch adds a test for an invalid output path for -Map option,
though that test is not for verifying that we are using error()
instead of fatal() in writeMapFile.

llvm-svn: 292336

Although this relocation type is not part of the x86-64 psABI, I intend to
use it internally as part of the ThinLTO implementation.

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

llvm-svn: 292330

llvm-svn: 292228

I found this when tried to link linux kernel with LLD:

https://github.com/torvalds/linux/blob/master/arch/x86/entry/vdso/vdso-layout.lds.S#L86

Output section command can have optional comma at the end:

.text		: { *(.text*) }			:text	=0x90909090,

It was documented about 3 years ago for binutils:
https://sourceware.org/ml/binutils/2014-04/msg00045.html

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

llvm-svn: 292225

Patch changes behavior to not try open the output 
file if we already know about error.

That is not just cleaner, but also fixes nasty behavior of linker that
could create huge temporarily files under certain conditions.

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

llvm-svn: 292219

llvm-svn: 292182

On MIPS .got section cannot be included into the PT_GNU_RELRO segment.
Sometimes it might work, but in general it is unsupported. One of the
problem is that all sections marked by SHF_MIPS_GPREL should be grouped
together because data in these sections is addressable with a gp
relative address, but such sections might be writable.

This patch exclude mips .got from PT_GNU_RELRO segment and group
SHF_MIPS_GPREL sections.

llvm-svn: 292161

LLD exports symbols that are also present in used shared libraries to
make sure they are preempted at runtime. That is a reasonable default,
but we must allow for it to be overwritten with linker script. If we
don't, libraries that expect to be able to hide a c++ delete operator
will fail.

This should fix the firebird build.

llvm-svn: 292146

I had a error in map-file.s testcase under MSVS2015/win32:

map-file.s:30:16: error: expected string not found in input
// CHECK-NEXT: 0000000000200158 0000000000000030 8 .eh_frame

<stdin>:2:1: note: scanning from here
0000000000200158 10 30 .eh_frame

Format string '%0*x' requires an argument of type 'unsigned int',
but argument has type 'uint64_t'. Proper format is '%0*llx' then.

This fixes testcase failture for me.

llvm-svn: 292102

llvm-svn: 292090

llvm-svn: 292049

llvm-svn: 292048

llvm-svn: 292046

llvm-svn: 292045

llvm-svn: 292044

llvm-svn: 292042

Previous code had a bug that if the program exits with an assert() or
fail() before the control reaches end of writeMapFile(), it leaves a
temporary file, because FileRemover's dtor isn't called in that case.

I could fix that by removeFileOnSignal() and other functions, but
I think we can simply write to the result file directly. I think
that is straightforward and easy to understand.

Additionally, that allows something like `-Map /dev/null` or a bash
hack such as `-Map >(grep symbol-im-looking-for)`. Previously,
that kind of things didn't work.

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

llvm-svn: 292041

llvm-svn: 291984

The format is not exactly the same as the one in bfd since bfd always
follows a linker script and prints it along.

llvm-svn: 291958

The freebsd dynamic linker doesn't check if the value is null (and it
is reasonable for it to do that). That means that producing a .so with
a null DT_INIT/DT_FINI causes the base address to be called.

This should fix the libreoffice build.

llvm-svn: 291944

These were 3 last synthetics that were added in addPredefinedSections() instead
of createSyntheticSections(). Now it is possible to move addition to correct common place.

Also patch fixes testcase which discards .shstrtab, by restricting doing that.

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

llvm-svn: 291908

Now we have the consistent interface for all log/warn/error/fatal functions.

llvm-svn: 291847

llvm-svn: 291840

llvm-svn: 291835

llvm-svn: 291834

llvm-svn: 291812

llvm-svn: 291811

The effect is that the nobits section gets space allocated on disk.

Both bfd and gold allow this with linker scripts. To try to keep
things simple in lld, always allow it for now.

llvm-svn: 291795

Summary: elf::fatal is declared "noreturn".

Reviewers: grimar

Subscribers: llvm-commits

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

llvm-svn: 291766

Previously we just crashed when had user defined
section .shstrtab, for example. Which name equals to synthetic one,
but have different type.

Testcase reveals an issue.

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

llvm-svn: 291765

Intention of change is to get rid of code duplication.
Decompressor was introduced in D28105.

Change allows to get rid of few methods relative to decompression.

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

llvm-svn: 291758

Addded quotes to be consistent with x64 messages,
where quotes were used for nicer reporting 'Unknown' relocations initially.

llvm-svn: 291752

The same we did for x86 earlier:
list supported relocations explicitly and error out on unknown.

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

llvm-svn: 291751

This matches what bfd and gold do. It also matches the common flags of
other .data sections.

llvm-svn: 291674

We had an error when met this relocation
after latest changes aboult listing
x86 relocations explicitly.

Since we support R_X86_64_NONE,
and GNU ld supports R_386_NONE,
it seems reasonable to have.

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

llvm-svn: 291672