This is PR28358
According to
https://www.akkadia.org/drepper/dsohowto.pdf
"The fourth point, the VERS 1.0 version being referred to in the VERS 2.0 definition, is not really important in symbol versioning. It marks the predecessor relationship of the two versions and it is done to maintain the similar- ities with Solaris’ internal versioning. It does not cause any problem it might in fact be useful to a human reader so predecessors should always be mentioned."
Patch partially reverts 273423 "[ELF] - Implemented version script hierarchies.",
version references are just ignored now.
Differential revision: http://reviews.llvm.org/D21888
llvm-svn: 274345
Option has next description (http://linux.die.net/man/1/ld):
"--unresolved-symbols=method
Determine how to handle unresolved symbols. There are four possible values for method
according to documentation:
ignore-all: Do not report any unresolved symbols.
report-all: Report all unresolved symbols. This is the default.
ignore-in-object-files: Report unresolved symbols that are contained in shared libraries, but ignore them if they come from regular object files.
ignore-in-shared-libs: Report unresolved symbols that come from regular object files, but ignore them if they come from shared libraries."
Since report-all is default and we traditionally do not report about undefined symbols in lld,
report-all does not report about undefines from DSO.
ignore-in-object-files also does not do that. Handling of that option differs from what gnu linkers do.
Option works in next way in lld:
ignore-all: Do not report any unresolved symbols.
report-all: Report all unresolved symbols except symbols from DSOs. This is the default.
ignore-in-object-files: The same as ignore-all.
gnore-in-shared-libs: The same as report-all.
This is PR24524.
Differential revision: http://reviews.llvm.org/D21794
llvm-svn: 274123
Previously BC files were not checked for the same platform etc,
That lead to confusing error "Invalid section header entry size (e_shentsize) in ELF header" when
mixing files for different architectures.
Patch fixes PR28324.
Differential revision: http://reviews.llvm.org/D21832
llvm-svn: 274113
So that users are not forced to pass `-m` on the command line
when the inputs are all bitcode.
PR: 28268
Differential Revision: http://reviews.llvm.org/D21779
llvm-svn: 274107
Example:
VERSION_1.0 {
global: foo*;
local: *; }
now correctly matches all the symbols which name starts with
`foo`.
Differential Revision: http://reviews.llvm.org/D21732
llvm-svn: 274091
t is possible to create new version of symbol instead of depricated one
using combination of version script and asm commands. For example:
__asm__(".symver b_1,b@LIBSAMPLE_1.0");
int b_1() { return 10; }
__asm__(".symver b_2,b@@LIBSAMPLE_2.0");
int b_2() { return 20; }
This code makes b_2() to be default implementation for b().
b_1() is used for compatibility with binaries compiled against
library of older version LIBSAMPLE_1.0.
This patch implements support for above functionality in lld.
Differential revision: http://reviews.llvm.org/D21681
llvm-svn: 274002
Option checks for cases where a version script explicitly lists
a symbol, but the symbol is not defined and errors out such
cases if any.
Differential revision: http://reviews.llvm.org/D21745
llvm-svn: 273998
Previously, we searched for a .so file from all library paths and
then searched for a .a file. That logic is wrong. What we need to
do is to look for a .so and a .a for each library path.
llvm-svn: 273846
Previously the next sample script would generate 2 entries in
Config->SymbolVersions with the same version name.
VERSION {
global: c;
};
That happened because parseVersionSymbols() was called twice.
At first for "global:" and since there is no local tag, it was called again.
Patch fixes the issue, testcase was updated to demonstrate.
Differential revision: http://reviews.llvm.org/D21640
llvm-svn: 273663
Patch implements support of zlib style compressed sections.
SHF_COMPRESSED flag is used to recognize that decompression is required.
After that decompression is performed and flag is removed from output.
Differential revision: http://reviews.llvm.org/D20272
llvm-svn: 273661
The patch adds one more partition to the MIPS GOT. This time it is for
TLS related GOT entries. Such entries are located after 'local' and 'global'
ones. We cannot get a final offset for these entries at the time of
creation because we do not know size of 'local' and 'global' partitions.
So we have to adjust the offset later using `getMipsTlsOffset()` method.
All MIPS TLS relocations which need GOT entries operates MIPS style GOT
offset - 'offset from the GOT's beginning' - MipsGPOffset constant. That
is why I add new types of relocation expressions.
One more difference from othe ABIs is that the MIPS ABI does not support
any TLS relocation relaxations. I decided to make a separate function
`handleMipsTlsRelocation` and put MIPS TLS relocation handling code
there. It is similar to `handleTlsRelocation` routine and duplicates its
code. But it allows to make the code cleaner and prevent pollution of
the `handleTlsRelocation` by MIPS 'if' statements.
Differential Revision: http://reviews.llvm.org/D21606
llvm-svn: 273569
Patch by Shridhar Joshi.
This option provides names of all the link time modules which define and
reference symbols requested by user. This helps to speed up application
development by detecting references causing undefined symbols.
It also helps in detecting symbols being resolved to wrong (unintended)
definitions in case of applications containing multiple definitions for
same symbols with different types, bindings.
Implements PR28226.
llvm-svn: 273536
Peter Smith found while trying to support thunk creation for ARM that
LLD sometimes creates broken thunks for MIPS. The cause of the bug is
that we assign file offsets to input sections too early. We need to
create all sections and then assign section offsets because appending
thunks changes file offsets for all following sections.
This patch separates the pass to assign file offsets from thunk
creation pass. This effectively reverts r265673.
Differential Revision: http://reviews.llvm.org/D21598
llvm-svn: 273532
This fixes PR28218. Thanks to Rafael for spotting a failure in
the SHARED_LIBS build!
Differential Revision: http://reviews.llvm.org/D21577
llvm-svn: 273451
Patch implements hierarchies for version scripts.
This allows to handle script files with dependencies, like next one has:
LIBSAMPLE_1.0{
global:
a;
};
LIBSAMPLE_2.0
{
global:
b;
}LIBSAMPLE_1.0;
Differential revision: http://reviews.llvm.org/D21556
llvm-svn: 273423
For next version script:
VER1{
global:
a;
};
VER2{
global:
a;
};
gold would produce warning like:
"warning: using 'VER1' as version for 'a' which is also named in version 'VER2' in script."
Documentation also says we do not want this duplications (https://people.freebsd.org/~deischen/symver/library_versioning.txt):
"Note that you do not want to duplicate symbols in the map file. The .symver directives are all that is required to add compatibility
symbols into old versions."
This patch restricts such mixing and makes lld to produce error in this case.
Differential revision: http://reviews.llvm.org/D21555
llvm-svn: 273396
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
George Rimar