This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.
The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.
The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.
Fixes PR32924
Differential Revision: https://reviews.llvm.org/D33280
llvm-svn: 303337
Nothing special here, just detemplates code that became possible
to detemplate after recent commits in a straghtforward way.
Differential revision: https://reviews.llvm.org/D33234
llvm-svn: 303237
SymbolTableBaseSection was introduced.
Detemplation of SymbolTableSection should allow to detemplate more things.
Differential revision: https://reviews.llvm.org/D33124
llvm-svn: 303150
Switch to llvm::to_integer() everywhere in LLD instead of
StringRef::getAsInteger() because API of latter is confusing.
It returns true on error and false otherwise what makes reading
the code incomfortable.
Differential revision: https://reviews.llvm.org/D33187
llvm-svn: 303149
We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.
This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.
A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.
Differential Revision: https://reviews.llvm.org/D33176
llvm-svn: 303089
We used to place orphans by just using compareSectionsNonScript.
Then we noticed that since linker scripts can use another order, we
should first try match the section to a given PT_LOAD. But there is
nothing special about PT_LOAD. The same issue can show up for
PT_GNU_RELRO for example.
In general, we have to search for the most similar section and put the
orphan next to it. Most similar being defined as how long they follow
the same code path in compareSecitonsNonScript.
That is what this patch does. We now compute a rank for each output
section, with a bit for each branch in what was
compareSectionsNonScript.
With this findOrphanPos is now fully general and orphan placement can
be optimized by placing every section with the same rank at once.
The included testcase is a variation of many-sections.s that uses
allocatable sections to avoid the fast path in the existing
code. Without threads it goes form 46 seconds to 0.9 seconds.
llvm-svn: 302903
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
Both gold and bfd restrict that one:
ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var
What looks reasonable because it is 32 bit one. Patch do the same.
Differential revision: https://reviews.llvm.org/D33100
llvm-svn: 302881
Previously we were not printing out the type of the incompatible section
which made it difficult to determine what the problem was.
The error message format has been change to the following:
error: section type mismatch for .shstrtab
>>> <internal>:(.shstrtab): SHT_STRTAB
>>> output section .shstrtab: Unknown
Patch by Alexander Richardson.
Differential Revision: https://reviews.llvm.org/D32488
llvm-svn: 302694
This behavior differs from the semantics implemented by GNU linkers
which only define this symbol iff ELF headers are in the memory
mapped segment.
Differential Revision: https://reviews.llvm.org/D33019
llvm-svn: 302687
This is PR32664.
Issue was revealed by linux kernel script which was:
SECTIONS {
. = (0xffffffff80000000 + ALIGN(0x1000000, 0x200000));
phys_startup_64 = ABSOLUTE(startup_64 - 0xffffffff80000000);
.text : AT(ADDR(.text) - 0xffffffff80000000) {
.....
*(.head.text)
Where startup_64 is in .head.text.
At the place of assignment to phys_startup_64 we can not calculate absolute value for startup_64
because .text section has no VA assigned. Two patches were prepared earlier to address this: D32173 and D32174.
And in comments for D32173 was suggested not try to support this case, but error out.
Differential revision: https://reviews.llvm.org/D32793
llvm-svn: 302668
When compiling LLD using GCC 7 it reports warnings like:
"warning: this statement may fall through [-Wimplicit-fallthrough=]"
LLVM has LLVM_FALLTHROUGH macro which can be used to avoid such warnings.
Together with D33036 this patch fixes them.
Differential revision: https://reviews.llvm.org/D32907
llvm-svn: 302666
Adds support for the ORIGIN and LENGTH linker script built in functions.
ORIGIN(memory) Return the origin of the memory region
LENGTH(memory) Return the length of the memory region
Redo of D29775 for refactored linker script parsing.
Patch by Robert Clarke
Differential Revision: https://reviews.llvm.org/D32934
llvm-svn: 302564
This is a bit easier to read and a lot faster in some cases. A version
of many-sections.s with linker scripts goes from 0m41.232s to
0m19.575s.
llvm-svn: 302528
The code following this one already considers every possible insertion
point for orphan sections, there is no point in sorting them before.
llvm-svn: 302441
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
Previously it was impossible to use linkerscript with --compress-debug-sections
because of assert failture:
Assertion failed: isFinalized(), file C:\llvm\lib\MC\StringTableBuilder.cpp, line 64
Patch fixes the issue
llvm-svn: 302413
We can set SectionIndex tentatively as we process the linker script
instead of looking it repeatedly.
In general we should try to have as few name lookups as possible.
llvm-svn: 302299
This feels a bit hackish, but I think it is still an improvement.
The way a tls address is computed in the various architectures is not
that different. For example, for local dynamic we need the base of the
tls (R_TLSLD or R_TLSLD_PC), and the offset of that particular symbol
(R_ABS).
Given the similarity, we can just use the expressions instead of
having two additional target hooks.
llvm-svn: 302279
The test ELF/lto/thin-archivecollision.ll was not testing what it
wanted to test. It needs two archive members with the same name, but
different offsets.
Without this we could remove all references of OffsetInArchive and all
tests would still pass.
Fixing the test showed that the --whole-archive case was broken, which
this patch fixes.
llvm-svn: 302241
Rafael Espindola