We really need to find a way to get this info from a single point of
truth in the LLVM backend, but it seems that the EM_* constants are
buried deep inside the constructors of the MCAsmBackend's.
For now, just fill in entries as we run into cases. AFAIK these mappings
are largely immutable, so we get a 75% discount on the technical debt
(code is duplicated, but little chance of divergence).
llvm-svn: 296429
With the current design an InputSection is basically anything that
goes directly in a OutputSection. That includes plain input section
but also synthetic sections, so this should probably not be a
template.
llvm-svn: 295993
We have InputSection, MergeInputSection and EhInputSection, so
isa<MergeInputSection> is equivalent to !isa<InputSection> && !isa<
EhInputSection>.
llvm-svn: 295937
LLD is a multi-threaded program. errs() or outs() are not guaranteed
to be thread-safe (they are actually not).
LLD's message(), log() or error() are thread-safe. We should use them.
llvm-svn: 295787
Previously LLD crashed on on provided testcases because "/DISCARD/" was
not supported. Patch implements that.
After this I think there is no known issues with --emit-relocs implementation
required for linux kernel linking.
Differential revision: https://reviews.llvm.org/D29273
llvm-svn: 295488
I splitted it from D29273.
Since we plan to make relocatable sections as dependent for target ones for
--emit-relocs implementation, this change is required to support .eh_frame case.
EhInputSection inherets from InputSectionBase and not from InputSection.
So for case when it has relocation section, it should be able to access DependentSections
vector.
This case is real for Linux kernel.
Differential revision: https://reviews.llvm.org/D30084
llvm-svn: 295483
That fixes a case when section has more than one metadata
section. Previously GC would collect one of such sections
because we had implementation that stored only last one as
dependent.
Differential revision: https://reviews.llvm.org/D29981
llvm-svn: 295298
If we had SHT_GROUP sections, then when -r was used we might crash.
This is PR31952.
Issue happened because we emited relocation section though its target was discared
because was a member of duplicated group. When we tried to get VA of target,
segfault happened.
Core cause is the bug that GNU as 2.27 (and probably later versions) has.
In compare with llvm-mc, it does not include relocation sections into the group,
like shown in testcase. This patch covers that case.
Differential revision: https://reviews.llvm.org/D29929
llvm-svn: 295067
with temporarily file name fix in testcase.
Original commit message:
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294469
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294464
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.
This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.
Differential revision: https://reviews.llvm.org/D29327
llvm-svn: 293757
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
llvm-svn: 293283
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
llvm-svn: 291474
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.
llvm-svn: 291413
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.
llvm-svn: 291219
This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.
Differential Revision: https://reviews.llvm.org/D28103
llvm-svn: 291210
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.
llvm-svn: 290951
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
llvm-svn: 290062
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
llvm-svn: 289642
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
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
llvm-svn: 288172
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
llvm-svn: 287787
Previously, we stored offsets in string tables to symbols, so
you needed to pass a string table to get a symbol name. This patch
stores const char pointers instead to eliminate the need to pass
a string table.
llvm-svn: 287737
LLD's error messages contain line numbers, function names or section names.
Currently they are formatter as follows.
foo.c (32): symbol 'foo' not found
foo.c (function bar): symbol 'foo' not found
foo.c (.text+0x1234): symbol 'foo' not found
This patch changes them so that they are consistent with Clang's output.
foo.c:32: symbol 'foo' not found
foo.c:(function bar): symbol 'foo' not found
foo.c:(.text+0x1234): symbol 'foo' not found
Differential Revision: https://reviews.llvm.org/D26901
llvm-svn: 287537
Patch adds a filename to that error message.
I faced next error when debugged one of FreeBSD port:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol __tls_get_addr
error message was poor and this patch improves it to show the locations
of symbol declaration and using.
Differential revision: https://reviews.llvm.org/D26508
llvm-svn: 286940
Found this when tried to link lang/ccl FreeBSD port.
Issue is very close to D23201.
This is the reason of lang/ccl port link fail.
GNU assembler 2.17.50 [FreeBSD] 2007-07-03 could generate broken objects,
where notype symbols are associated with symtab:
...
[ 9] .symtab SYMTAB 0000000000000000 00003c78
0000000000006858 0000000000000018 10 803 8
...
192: 000000000000000d 0 NOTYPE LOCAL DEFAULT 9 _cons_org
Patch allows to handle such objects.
Differential revision: https://reviews.llvm.org/D26613
llvm-svn: 286939
The functions getBitcodeTargetTriple(), isBitcodeContainingObjCCategory(),
getBitcodeProducerString() and hasGlobalValueSummary() now return errors
via their return value rather than via the diagnostic handler.
To make this work, re-implement these functions using non-member functions
so that they can be used without the LLVMContext required by BitcodeReader.
Differential Revision: https://reviews.llvm.org/D26532
llvm-svn: 286623
The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.
Change lld uses to the appropriate split header, removing it
completely in one case where it wasn't needed.
llvm-svn: 286568
Relocations are the last thing that we wore storing a raw section
pointer to and parsing on demand.
With this patch we parse it only once and store a pointer to the
actual data.
The patch also changes where we store it. It is now in
InputSectionBase. Not all sections have relocations, but most do and
this simplifies the logic. It also means that we now only support one
relocation section per section. Given that that constraint is
maintained even with -r with gold bfd and lld, I think it is OK.
llvm-svn: 286459
Previously, we have both input and output section for .MIPS.abiflags.
Now we have only one class for .MIPS.abiflags, which is MipsAbiFlagsSection.
This class is a synthetic input section.
.MIPS.abiflags sections are handled as regular sections until
the control reaches Writer. Writer then aggregates all sections
whose type is SHT_MIPS_ABIFLAGS to create a single synthesized
input section. The synthesized section is then processed normally
as if it came from an input file.
llvm-svn: 286398
Previously, we have both input and output sections for .reginfo and
.MIPS.options. Now for each such sections we have one synthetic input
sections: MipsReginfoSection and MipsOptionsSection respectively.
Both sections are handled as regular sections until the control reaches
Writer. Writer then aggregates all sections whose type is SHT_MIPS_REGINFO
or SHT_MIPS_OPTIONS to create a single synthesized input section. In that
moment Writer also save GP0 value to the MipsGp0 field of the corresponding
ObjectFile. This value required for R_MIPS_GPREL16 and R_MIPS_GPREL32
relocations calculation.
Differential revision: https://reviews.llvm.org/D26444
llvm-svn: 286397
Instead of remembering a raw Elf_Shdr, store the symbol table proper
and the index of the first non local.
This moves error handling upfront and simplifies it.
llvm-svn: 285933
DIHelper is a class having only one member, and ObjectFile has
a unique pointer to a DIHelper. So we can directly have ObjectFile
have the member.
Differential Revision: https://reviews.llvm.org/D26223
llvm-svn: 285850
When we have SHT_GNU_versym section, it is should be associated with symbol table
section. Usually (and in out implementation) it is .dynsym.
In case when .dynsym is absent (due to broken object for example),
lld crashes in parseVerdefs() when accesses null pointer:
Versym = reinterpret_cast<const Elf_Versym *>(this->ELFObj.base() +
VersymSec->sh_offset) +
this->Symtab->sh_info;
DIfferential revision: https://reviews.llvm.org/D25553
llvm-svn: 285796
Previously, we have a lot of BumpPtrAllocators, but all these
allocators virtually have the same lifetime because they are
not freed until the linker finishes its job. This patch aggregates
them into a single allocator.
Differential revision: https://reviews.llvm.org/D26042
llvm-svn: 285452
Instead of having 3 section allocators per file, have 3 for all files.
This is a substantial performance improvement for some cases. Linking
chromium without gc speeds up by 1.065x.
This requires using _exit in fatal since we have to avoid destructing
an InputSection if fatal is called from the constructor.
Thanks to Rui for the suggestion.
llvm-svn: 285290
We used to have one allocator per file, which reduces the advantage of
using an allocator in the first place.
This is a small speed up is most cases. The largest speedup was in
1.014X in chromium no-gc. The largest slowdown was scylla at 1.003X.
llvm-svn: 285205
This patch make lld show following details for undefined symbol errors:
- file (line)
- file (function name)
- file (section name + offset)
Differential revision: https://reviews.llvm.org/D25826
llvm-svn: 285186
This is not particularly efficient, but does avoid exposing Comdat*
out of LTO.h.
I will send a patch for review with a more efficient interface that
should map nicely to a bitcode symbol table.
llvm-svn: 284413
Rui Ueyama