This change introduces new synthetic sections IpltSection, IgotPltSection
that represent the ifunc entries that would previously have been put in
the PltSection and the GotPltSection. The separation makes sure that
the R_*_IRELATIVE relocations are placed after the non R_*_IRELATIVE
relocations, which permits ifunc resolvers to know that the .got.plt
slots will be initialized prior to the resolver being called.

A secondary benefit is that for ARM we can move the IgotPltSection and its
dynamic relocations to the .got and .rel.dyn as the ARM glibc expects all
the R_*_IRELATIVE relocations to be in the .rel.dyn

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

llvm-svn: 289045

These MIPS specific symbols should be global because in general they can
have an arbitrary value. By default this value is a fixed offset from .got
section.

This patch adds more checks to the mips-gp-local.s test case but marks
it as XFAIL because LLD does not allow redefinition of absolute symbols
value by a linker script. This should be fixed by D27276.

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

llvm-svn: 289025

Thanks to George Rimar for pointing it out.

llvm-svn: 289020

Obj is an instance of std::unique_ptr, so *Obj.get() is the same as *Obj.

llvm-svn: 288996

clang-format-diff sorted these #include's in the asciibetical order,
but they need to be in this order.

llvm-svn: 288995

llvm-svn: 288993

Previously, we had different way to stringize SymbolBody and InputFile
to construct error messages. This patch defines overloaded function
toString() so that we don't need to memorize all these different
function names.

With that change, it is now easy to include demangled names in error
messages. Now, if there is a symbol name conflict, we'll print out
both mangled and demangled names.

llvm-svn: 288992

Thanks to Rui for the suggestion.

llvm-svn: 288982

llvm-svn: 288975

Now Target->MaxPageSize is only used as the default value of
Config->MaxPageSize.

llvm-svn: 288974

Line number can never contain '/' or '\', so the previous code
was pointless at that point.

llvm-svn: 288973

llvm-svn: 288972

llvm-svn: 288971

Found by inspection.

llvm-svn: 288970

llvm-svn: 288967

Currently LLD prints basename of source file name in error messages,
for example:
$ mkdir foo
$ echo 'void _start(void) { foobar(); }' > foo/bar.c
$ gcc -g -c foo/bar.c
$ bin/ld.lld -o out bar.o 
bin/ld.lld: error: bar.c:1: undefined symbol 'foobar'
$
This should say:
bin/ld.lld: error: foo/bar.c:1: undefined symbol 'foobar'

This is PR31299

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

llvm-svn: 288966

This patch refactor how to apply the R_AARCH64_LDST{8,16,32,64,128}_ABS_NC
relocations by adding a new function to correct extract the bits expected
by each relocation.  This make is explicit which are the bits range expected
and simplify the code to mask and shift the deriable values.

It also fixes the R_AARCH64_LDST128_ABS_LO12_NC mask, although in pratice
the mask/shift always returns a 16 bytes aligned value.

Checked on AArch64 and with test-suite.

llvm-svn: 288921

llvm-svn: 288885

Config->WarnMissingEntry is a single-purpose boolean variable, and
I think it's easier to understand than Config->HasEntry.

llvm-svn: 288883

This patch is to parse the entry symbol name lazily.

llvm-svn: 288882

This is related to the change in handling of entry point symbols.

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

llvm-svn: 288880

Shared libraries should have entry set following the same rules as for
regular binaries. The only difference is that in case the default entry
point (_start or __start) isn't found (unless it was set explicitly), we
shouldn't give a warning as in case of regular binaries.

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

llvm-svn: 288878

The presence of DT_DEBUG entry is unrelated to the existence of entry point.

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

llvm-svn: 288877

Minor patch to fix PR31288

OpenBSD commit:
https://github.com/openbsd/src/commit/d39116912b9536bd77326260dc5c6e593fd4ee24

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

llvm-svn: 288832

If we do, the freebsd dynamic linker tries to call mmap with a size 0,
which fails.

It is hard to avoid creating them when linker scripts are used, so we
just delete empty PT_LOADs at the end.

llvm-svn: 288808

For preemptable symbols the dynamic linker does all the work. Trying
to compute the addend is at best wasteful and can also lead to crashes
in cases of programs that uses tls but doesn't define any tls
variables.

llvm-svn: 288803

llvm-svn: 288802

This change seems to make LLD 0.6% faster when linking Clang with
debug info. I don't want us to have lots of local optimizations,
but this function is very hot, and the improvement is small but
not negligible, so I think it's worth doing.

llvm-svn: 288757

This test only needs to test the Type (SharedObject), the address of
the first PT_LOAD and the presence of PT_DYNAMIC.

llvm-svn: 288719

It only needs to find how many are local.

llvm-svn: 288716

That patch broke build.

llvm-svn: 288708

llvm-svn: 288707

llvm-svn: 288704

llvm-svn: 288702

This test is just about which symbols are in which table.

llvm-svn: 288701

llvm-svn: 288700

Looks like the second section in this test was lost along the way.

llvm-svn: 288699

llvm-svn: 288686

Also add a citation to GNU gold safe ICF paper.

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

llvm-svn: 288684

On Linux (and probably on other Unix-like systems), unlink(2) is
noticeably slow. It takes 250 milliseconds to remove a 1 GB file
on ext4 filesystem on my machine, whether the file is on SSD or
on a spinning disk.

To create a new result file, we remove existing file first. So, if
you repeatedly link a 1 GB program in a regular compile-link-debug
cycle, every cycle wastes 250 milliseconds only to remove a file.

Since LLD can link a 1 GB in about 5 seconds, that waste actually
matters.

This patch defines `unlinkAsync` function. The function spawns a
background thread to call unlink. The calling thread returns
almost immediately.

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

llvm-svn: 288680