This patch is to rewrite the function with a table-lookup-ish approach
so that it can read as a series of "convert this pattern to this" pattern.
llvm-svn: 273238
With fix:
-soname flag was not set in testcase. Hash calculated for base def was different on local
and bot machines because filename fos used for calculating.
Initial commit message:
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273152
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273143
There are two motivations for this patch. The first one is a preparation
for support MIPS TLS relocations. It might sound like a joke but for GOT
entries related to TLS relocations MIPS ABI uses almost regular approach
with creation of dynamic relocations for each GOT enty etc. But we need
to separate these 'regular' TLS related entries from MIPS specific local
and global parts of GOT. ABI declare simple solution - all TLS related
entries allocated at the end of GOT after local/global parts. The second
motivation it to support GOT relocations for non-preemptible symbols
with addends. If we have more than one GOT relocations against symbol S
with different addends we need to create GOT entries for each unique
Symbol/Addend pairs.
So we store all MIPS GOT entries in separate containers. For non-preemptible
symbols we have to maintain two data structures. The first one is MipsLocal
vector. Each entry corresponds to the GOT entry from the 'local' part
of the GOT contains the symbol's address plus addend. The second one
is MipsLocalMap. It is a map from Symbol/Addend pair to the GOT index.
Differential Revision: http://reviews.llvm.org/D21297
llvm-svn: 273127
Doing that in an anonymous version is a bit silly, but this opens the
way for supporting it in general.
Since we don't support actual versions, for now we just disable the
version script if we detect that it is missing a local.
llvm-svn: 273000
Patch updates the version script parser to parse versioned files.
In a simple way, just adding them to VersionScriptGlobals list.
Differential revision: http://reviews.llvm.org/D21439
llvm-svn: 272934
Add support for the R_ARM_THM relocations used in the objects present
in arm-linux-gnueabihf-gcc. These are:
R_ARM_THM_CALL
R_ARM_THM_JUMP11
R_ARM_THM_JUMP19
R_ARM_THM_JUMP24
R_ARM_THM_MOVT_ABS
R_ARM_THM_MOVW_ABS_NC
Interworking between ARM and Thumb is partially supported with BLX.
The R_ARM_CALL relocation for ARM instructions and R_ARM_THM_CALL
relocation for Thumb instructions will write out a BL or BLX depending
on the state of the Target.
Assumptions:
- Availability of BLX and extended range of Thumb 4-byte Branch
instructions.
- In relocateOne if (Val & 0x1) == 1 target is Thumb, 0 is ARM.
This will hold for objects that comply with the ABI for the
ARM architecture.
This is sufficient for hello world to work with a recent
arm-linux-gnueabihf distribution.
Limitations:
No interworking for R_ARM_JUMP24, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19
and the deprecated R_ARM_PLT32 and R_ARM_PC24 instructions as these
cannot be written out as a BLX and need a state change thunk.
No range extension thunks. The R_ARM_JUMP24 and R_ARM_THM_CALL have a
range of 16Mb
llvm-svn: 272881
This should never happen with correct programs, but it is trivial
write a testcase where lld would crash or report duplicated
symbols. We now behave like when an archive is used and include the
file only once.
llvm-svn: 272724
Previously message told us that relocations could
not be used when making shared object. That was
correct because message could appear (and it is expected)
when we linked executable.
Message should have being changed to something
that says we can't use a subset of relocations against shared
symbols.
Patch fixes the text.
llvm-svn: 272478
Initially we wanted to check that these two relocations are not present when linking DSO because of
possible overflow in runtime. Patch moves them to writable segment in testcases to allow
proper error check to trigger.
Otherwise error message about using dynamic relocations against text segment was shown.
Differential revision: http://reviews.llvm.org/D21184
llvm-svn: 272379
It was reported in PR28020, that lld does not link code which
gold do. But in fact that is expected behavior as we do not
support DT_TEXTREL.
This patch changes error message as it can report about relocations against
text segments exclusively, other dynamic relocations errors can
be handled separately.
Differential revision: http://reviews.llvm.org/D21133
llvm-svn: 272377
We can now use this to decide whether to emit a verneed during the final
pass over the symbols. We were previously wrongly creating a verneed entry
in the case where all references to a DSO's symbols were weak.
In a future change we may also want to use the used bit to control whether
shared symbols are preemptible and appear in the dynsym. This seems a little
tricky to do at the moment because isNeeded() is templated.
The only other functional change here is that we emit a DT_NEEDED for DSOs
whose symbols are all preempted by objects that appear later in the link. But
that doesn't seem too important to me.
Differential Revision: http://reviews.llvm.org/D21171
llvm-svn: 272282
If the symbol is local we don't need to create a R_X86_64_DTPOFF64, we
can just write the correct value in the got.
Should fix pr28018.
llvm-svn: 272205
Previously this test performed check of binary data. Since
llvm-readobj currently able to dump all 3 types of version relative
sections, that can be used to make this test more transparent.
Patch do that.
Differential revision: http://reviews.llvm.org/D21024
llvm-svn: 272120
Add support for an ARM Target and the initial set of relocations
and PLT entries that are necessary for an ARM only hello world to
link. This has been tested against an ARM only sysroot from the
4.2.0 CodeSourcery Lite release.
Tests have been added to test/ELF for the support that has been
implemented.
Main limitations:
- No Thumb support
- Relocations incomplete
- No C++ exceptions support
- No TLS support
- No range extension or interworking veneer (thunk) support
- No Build Attribute support
- No Big-endian support
The deprecated relocations R_ARM_PLT32 and R_ARM_PC24 have been
implemented as these are used by the 4.2.0 CodeSourcery Lite release.
llvm-svn: 271993
This is mostly extracted from http://reviews.llvm.org/D18960.
The general idea for tlsdesc is that the two GD got entries are used
for a function pointer and its argument. The dynamic linker sets
both. In the non-dlopen case the dynamic linker sets the function to
the identity and the argument to the offset in the tls block.
All that the static linker has to do in the non-dlopen case is
relocate the code to point to the got entries and create a dynamic
relocation.
The dlopen case is more complicated, but can be implemented in another patch.
llvm-svn: 271569
Rafael Espindola