Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@293283 91177308-0d34-0410-b5e6-96231b3b80d8
The linkonce feature is a sort of proto-comdat. As far as I am aware no
compiler produces linkonce sections anymore, but some glibc i386 object
files contain definitions of symbol "__x86.get_pc_thunk.bx" in linkonce
sections. Drop those sections to avoid duplicate symbol errors.
This is glibc PR20543, we should remove this hack once that has been
fixed for a while.
Fixes PR31215.
Differential Revision: https://reviews.llvm.org/D28430
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291474 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291413 91177308-0d34-0410-b5e6-96231b3b80d8
In order to keep symbol lookup a simple name lookup this patch adds
versioned symbols with an explicit @ to the symbol table.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291293 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, when we printed out a path obtained from DWARF debug info,
we replaced \ with / on Windows. But that doesn't make sense. We should
respect the system's path separator.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291219 91177308-0d34-0410-b5e6-96231b3b80d8
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290951 91177308-0d34-0410-b5e6-96231b3b80d8
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290062 91177308-0d34-0410-b5e6-96231b3b80d8
The eglibc library, as used by Ubuntu 14.04 requires the presence of an
SHT_ARM_ATTRIBUTES section in for the purposes of checking hard/soft float
compatibility when dlopen() is used. Unfortunately when the section is not
present dlopen() fails with a generic could not find file message.
This change makes lld keep the first .ARM.attributes section that it
encounters and propagates it to the output. This is not a complete
SHT_ARM_ATTRIBUTES implementation, that would involve reading the contents
of the section and joining each individual attribute. It should suffice
for a homogenous build all libraries and executables on the same system
with a compatible set of command line options.
Differential revision: https://reviews.llvm.org/D27718
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289642 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288966 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is to avoid an implicit conversion from const char * to
StringRefZ, to make it apparent where we are using StringRefZ.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288182 91177308-0d34-0410-b5e6-96231b3b80d8
StringRefZ is a class to represent a null-terminated string. String
length is computed lazily, so it's more efficient than StringRef to
represent strings in string table.
The motivation of defining this new class is to merge functions
that only differ in string types; we have many constructors that takes
`const char *` or `StringRef`. With StringRefZ, we can merge them.
Differential Revision: https://reviews.llvm.org/D27037
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288172 91177308-0d34-0410-b5e6-96231b3b80d8
We have different functions to stringize objects to construct
error messages. For InputFile, we have getFilename, and for
InputSection, we have getName. You had to memorize them.
I think this is the case where the function overloading comes in handy.
This patch defines toString() functions that are overloaded for all these
types, so that you just call it in error().
Differential Revision: https://reviews.llvm.org/D27030
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287787 91177308-0d34-0410-b5e6-96231b3b80d8