| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
@gottpoff relocations were used at the same time.
Combination of @tlsgd and @gottpoff at the same time leads to miss of R_X86_64_TPOFF64 dynamic relocation. Patch fixes that.
@tlsgd(%rip) - Allocate two contiguous entries in the GOT to hold a tls index
structure (for passing to tls get addr).
@gottpoff(%rip) - Allocate one GOT entry to hold a variable offset in initial TLS
block (relative to TLS block end, %fs:0).
The same situation can be observed for x86 (probably others too, not sure) with corresponding for that target relocations: @tlsgd, @gotntpoff.
Differential revision: http://reviews.llvm.org/D15105
llvm-svn: 254443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix was:
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
=>
uint32_t getLocalTlsIndexVA() { return Base::getVA() + LocalTlsIndexOff; }
Both works for my MSVS.
Original commit message:
[ELF] - Refactor of tls_index implementation for tls local dynamic model.
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic model.
It failed buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/3782/steps/build/logs/stdio
Target.cpp
In file included from /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/Target.cpp:20:
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/OutputSections.h:136:42: error: use of undeclared identifier 'getVA'
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
llvm-svn: 254432
|
|
|
|
|
|
|
|
| |
Removes Target::getGotRefReloc() method to simplify Target class a little.
Differential revision: http://reviews.llvm.org/D15107
llvm-svn: 254429
|
|
|
|
|
|
|
|
|
|
| |
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254428
|
|
|
|
| |
llvm-svn: 254111
|
|
|
|
|
|
|
|
|
| |
Implements @tlsld (LD to LE) and @tlsgd (GD to LE) optimizations.
Patch does not implement the GD->IE case for @tlsgd.
Differential revision: http://reviews.llvm.org/D14870
llvm-svn: 254101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements next relocations:
R_386_TLS_LE - Negative offset relative to static TLS (GNU version).
R_386_TLS_LE_32 - Offset relative to static TLS block.
These ones are created when using next code sequences:
* @tpoff - The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
* @ntpoff Calculate the negative offset of the variable it is added to relative to the static TLS block.
The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
Information was found in Ulrich Drepper, ELF Handling For Thread-Local Storage, http://www.akkadia.org/drepper/tls.pdf, (6.2, p76)
Differential revision: http://reviews.llvm.org/D14930
llvm-svn: 254090
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-26/index.html says:
R_386_GOTPC
Resembles R_386_PC32, except that it uses the address of the global offset table in its calculation. The symbol referenced in this relocation normally is _GLOBAL_OFFSET_TABLE_, which also instructs the link-editor to create the global offset table.
Currently _GLOBAL_OFFSET_TABLE_ has value == zero. And we use GOT address to calculate the relocation. This patch does not changes that. It just removes the method which is used only for x86. So it is close to non functional change.
Differential revision: http://reviews.llvm.org/D14993
llvm-svn: 254088
|
|
|
|
|
|
|
|
| |
R_X86_64_GOTTPOFF is not always requires GOT entries. Some relocations can be converted to local ones.
Differential revision: http://reviews.llvm.org/D14713
llvm-svn: 253966
|
|
|
|
|
|
|
|
|
|
|
| |
R_AARCH64_LD64_GOT_LO12_NC.
With these relocations, it is now possible to build a simple "hello world"
program for AArch64 Debian.
Differential revision: http://reviews.llvm.org/D14917
llvm-svn: 253957
|
|
|
|
| |
llvm-svn: 253351
|
|
|
|
|
|
|
|
| |
Generates single GOT entry, R_X86_64_TPOFF64 is added to RelaDyn.
Differential revision: http://reviews.llvm.org/D14621
llvm-svn: 253049
|
|
|
|
|
|
| |
configuration.
llvm-svn: 253043
|
|
|
|
| |
llvm-svn: 252982
|
|
|
|
| |
llvm-svn: 252979
|
|
|
|
| |
llvm-svn: 252864
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for:
* Uniquing CIEs
* Dropping FDEs that point to dropped sections
It drops 657 488 bytes from the .eh_frame of a Release+Asserts clang.
The link time impact is smallish. Linking clang with a Release+Asserts
lld goes from 0.488064805 seconds to 0.504763060 seconds (1.034 X slower).
llvm-svn: 252790
|
|
|
|
|
|
| |
This will get a non st_value use shortly.
llvm-svn: 252753
|
|
|
|
| |
llvm-svn: 252745
|
|
|
|
|
|
| |
If linking a 32 bit binary, these values must fit in 32 bits.
llvm-svn: 252739
|
|
|
|
| |
llvm-svn: 252736
|
|
|
|
| |
llvm-svn: 252718
|
|
|
|
|
|
|
| |
This is in preparation for adding .eh_frame support. They will have
another input section type but will also need to be relocated.
llvm-svn: 252717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
leaq symbol@tlsld(%rip), %rdi
call __tls_get_addr@plt
symbol@tlsld (R_X86_64_TLSLD) instructs the linker to generate a tls_index entry (two GOT slots) in the GOT for the entire module (shared object or executable) with an offset of 0. The symbol for this GOT entry doesn't matter (as long as it's either local to the module or null), and gold doesn't put a symbol in the dynamic R_X86_64_DTPMOD64 relocation for the GOT entry.
All other platforms defined in http://www.akkadia.org/drepper/tls.pdf except for Itanium use a similar model where global and local dynamic GOT entries take up 2 contiguous GOT slots, so we can handle this in a unified manner if we don't care about Itanium.
While scanning relocations we need to identify local dynamic relocations and generate a single tls_index entry in the GOT for the module and store the address of it somewhere so we can later statically resolve the offset for R_X86_64_TLSLD relocations. We also need to generate a R_X86_64_DTPMOD64 relocation in the RelaDyn relocation section.
This implementation is a bit hacky. It side steps the issue of GotSection and RelocationSection only handling SymbolBody entries by relying on a specific relocation type. The alternative to this seemed to be completely rewriting how GotSection and RelocationSection work, or using a different hacky signaling method.
llvm-svn: 252682
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14171
llvm-svn: 251644
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14090.
llvm-svn: 251526
|
|
|
|
|
|
| |
This function is useful for ICF, so move that to a common place.
llvm-svn: 251455
|
|
|
|
| |
llvm-svn: 251241
|
|
|
|
| |
llvm-svn: 251212
|
|
|
|
| |
llvm-svn: 251140
|
|
|
|
|
|
|
|
|
|
|
| |
relocateOne is a function to apply a relocation. Previously, that
function took a pointer to Elf_Rel or Elf_Rela in addition to other
information that can be derived from the relocation entry. This patch
simplifies the parameter list. The new parameters, P or SA, are used
in the ELF spec to describe each relocation. These names make
relocateOne look like a mechanical, direct translation of the ELF spec.
llvm-svn: 251090
|
|
|
|
|
|
| |
We would get the wrong value if the symbol was in the middle of an entry.
llvm-svn: 250865
|
|
|
|
|
|
| |
For now SHF_STRINGS are not supported.
llvm-svn: 250737
|
|
|
|
|
|
|
|
|
| |
Given the name, it is natural for this function to compute the full target.
This will simplify SHF_MERGE handling by allowing getLocalRelTarget to
centralize the addend logic.
llvm-svn: 250731
|
|
|
|
|
|
|
|
| |
If one file is MIPS64EL, all files are MIPS64EL, and vice versa.
We do not have to look up MIPS-ness for each file. Currently we
do not support 64-bit MIPS, so the config value is always false.
llvm-svn: 250566
|
|
|
|
|
|
|
| |
As pointed out by Rafael (with a further suggestion by Rui), the new Type
parameter I added in r250555 is not needed. Remove it.
llvm-svn: 250563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
R_PPC64_TOC does not have an associated symbol, but does have a non-zero VA
that target-specific code must compute using some non-trivial rule. We
handled this as a special case in PPC64TargetInfo::relocateOne, where
we knew to write this special address, but that did not work when creating shared
libraries. The special TOC address needs to be the subject of a
R_PPC64_RELATIVE relocation, and so we also need to know how to encode this
special address in the addend of that relocation.
Thus, some target-specific logic is necessary when creating R_PPC64_RELATIVE as
well. To solve this problem, we teach getLocalRelTarget to handle R_PPC64_TOC
as a special case. This allows us to remove the special case in
PPC64TargetInfo::relocateOne (simplifying code there), and naturally allows the
existing logic to do the right thing when creating associated R_PPC64_RELATIVE
relocations for shared libraries.
llvm-svn: 250555
|
|
|
|
| |
llvm-svn: 250447
|
|
|
|
|
|
|
|
|
|
|
| |
When a relocation points to a SHF_MERGE section, the addend has special meaning.
It should be used to find what in the section the relocation points to. It
should not be added to the output position.
Centralizing it means that the above rule will be implemented once, not once
per target.
llvm-svn: 250421
|
|
|
|
|
|
| |
We have OutputSection<ELFT> type. GCC 4.9.2 warns on the duplication.
llvm-svn: 250358
|
|
|
|
|
|
| |
It was creating a local var with the same name as the member var.
llvm-svn: 250347
|
|
|
|
|
|
|
| |
These accessors didn't provide any additional value over a public
member variable, too.
llvm-svn: 250328
|
|
|
|
|
|
|
| |
These accessors didn't provide any additional value over a public
member variable.
llvm-svn: 250326
|
|
|
|
|
|
|
| |
This can show up with a non-PIC .o being linked into an executable that uses
shared libraries.
llvm-svn: 250300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under the PPC64 ELF ABI, functions that might call into other modules (and,
thus, need to load a different TOC base value into %r2), need to restore the
old value after the call. The old value is saved by the .plt code, and the
caller only needs to include a nop instruction after the call, which the linker
will transform into a TOC restore if necessary.
In order to do this the relocation handler needs two things:
1. It needs to know whether the call instruction it is modifying is targeting
a .plt stub that will load a new TOC base value (necessitating a restore after
the call).
2. It needs to know where the buffer ends, so that it does not accidentally
run off the end of the buffer when looking for the 'nop' instruction after the
call.
Given these two pieces of information, we can insert the restore instruction in
place of the following nop when necessary.
llvm-svn: 250110
|
|
|
|
| |
llvm-svn: 250096
|
|
|
|
|
|
| |
And remove git getLocalSymVA because there's no user of the function anymore.
llvm-svn: 250095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds AsNeeded and IsUsed bool fields to SharedFile. AsNeeded bit
is set if the DSO is enclosed with --as-needed and --no-as-needed. IsUsed
bit is off by default. When we adds a symbol to the symbol table for dynamic
linking, we set its SharedFile's IsUsed bit.
If AsNeeded is set but IsUsed is not set, we don't want to write that
file's SO name to DT_NEEDED field.
http://reviews.llvm.org/D13579
llvm-svn: 249998
|
|
|
|
| |
llvm-svn: 249729
|