This is a bit of an odd feature. It is normally used in
. = SEGMENT_START(seg, val);
In bfd it evaluates to val or to the value of the corresponding
-T<seg>-segment. Note that the -T<seg>-segment in bfd doesn't actually
change the segment address, just the value this evaluates too,
including in the default linker script.
In gold the -T<seg>-segment options do change the segment address and
seeing this expressions in linker scripts disables the options.
For new this just always evaluates the expression to val.
llvm-svn: 277014
The previous run line depended on libSystem.dylib being present, which it's not
on non-darwin platforms. The new run line uses libSystem.yaml instead.
llvm-svn: 276999
Some scripts can contain SORT(CONSTRUCTORS) expression:
https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?revision=284870&view=markup#l152
for ELF it just a nop:
"When linking object file formats which do not support arbitrary sections, such as ECOFF and XCOFF, the linker will automatically recognize C++ global constructors and destructors by name. For these object file formats, the CONSTRUCTORS command tells the linker to place constructor information in the output section where the CONSTRUCTORS command appears. The CONSTRUCTORS command is ignored for other object file formats."
(http://www.sourceware.org/binutils/docs-2.10/ld_3.html)
So patch implements ignoring.
Differential revision: https://reviews.llvm.org/D22848
llvm-svn: 276965
This patch causes LLD to build stabs debugging symbols for files containing
DWARF debug info, and to propagate existing stabs symbols for object files
built using '-r' mode. This enables debugging of binaries generated by LLD
from MachO objects.
llvm-svn: 276921
In compare with what GNU linkers do (https://sourceware.org/binutils/docs/ld/Builtin-Functions.html),
this implementation simple:
Do not touch DATA_SEGMENT_ALIGN, it do what it do now - just aligns to the page boundary.
Parameters of DATA_SEGMENT_RELRO_END is ignored. That should be correct as it is usually just a 24 bytes
shift that allows to protect first 3 entries of got.plt with relro.
(https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?revision=284870&view=markup#l146).
DATA_SEGMENT_RELRO_END just aligns to the page boundary.
That is what expected because all sections that are not affected by relro should be on another memory page.
So at fact the difference with documented behavior is that we do not pad DATA_SEGMENT_ALIGN.
3 entries of got.plt are uncovered by relro, but functionality is simple and equal to lld behavior
for case when script is not given.
Differential revision: https://reviews.llvm.org/D22813
llvm-svn: 276778
We can simplify the evaluation of DATA_SEGMENT_ALIGN
just to simple align(). That way it will work exactly like we have in non-script case.
Change was suggested by Rafael Ávila de Espíndola
Differential revision: https://reviews.llvm.org/D22807
llvm-svn: 276745
This flag is implemented similarly to --reproduce in the ELF linker.
This patch implements /linkrepro by moving the cpio writer and associated
utility functions to lldCore, and using that implementation in both linkers.
One COFF-specific detail is that we store the object file from which the
resource files were created in our reproducer, rather than the resource
files themselves. This allows the reproducer to be used on non-Windows
systems for example.
Differential Revision: https://reviews.llvm.org/D22418
llvm-svn: 276719
PROVIDE request us to define a symbol only if it is referenced and is
not defined by any object included in the link. We created the
symbol in the symbol table no matter what.
Differential Revision: https://reviews.llvm.org/D22739
llvm-svn: 276592
Previously, we handled an expression as a vector of tokens. In other
words, an expression was a vector of uncooked raw StringRefs.
When we need a value of an expression, we used ExprParser to run
the expression.
The separation was needed essentially because parse time is too
early to evaluate an expression. In order to evaluate an expression,
we need to finalize section sizes. Because linker script parsing
is done at very early stage of the linking process, we can't
evaluate expressions while parsing.
The above mechanism worked fairly well, but there were a few
drawbacks.
One thing is that we sometimes have to parse the same expression
more than once in order to find the end of the expression.
In some contexts, linker script expressions have no clear end marker.
So, we needed to recognize balanced expressions and ternary operators.
The other is poor error reporting. Since expressions are parsed
basically twice, and some information that is available at the first
stage is lost in the second stage, it was hard to print out
apprpriate error messages.
This patch fixes the issues with a new approach.
Now the expression parsing is integrated into ScriptParser.
ExprParser class is removed. Expressions are represented as lambdas
instead of vectors of tokens. Lambdas captures information they
need to run themselves when they are created.
In this way, ends of expressions are naturally detected, and
errors are handled in the usual way. This patch also reduces
the amount of code.
Differential Revision: https://reviews.llvm.org/D22728
llvm-svn: 276574
Otherwhise undefined references to symbols defined in linker scripts
are never resolved.
Differential Revision: https://reviews.llvm.org/D22664
llvm-svn: 276536
Not all relocations from a .eh_frame that point to an executable
section should be ignored. In particular, the relocation finding the
personality function should not.
This is a reduction from trying to bootstrap a static lld on linux.
llvm-svn: 276329
It is called basic because:
CONSTANT expression can refer to COMMONPAGESIZE and MAXPAGESIZE.
This sizes are usually different and used for possible optimization of
memory consumption.
More details are here: https://sourceware.org/ml/binutils/2002-02/msg00265.html
We currently do not support this optimization, so both CONSTANT(MAXPAGESIZE)
and CONSTANT(COMMONPAGESIZE) just return Target->PageSize value.
DATA_SEGMENT_ALIGN and DATA_SEGMENT_END are used as a part of opt.
The latter one is just ignored now.
According to documentation DATA_SEGMENT_ALIGN has 2 possible
calculation, but since we do not support mentioned opt - it
is always calculated now as (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - 1))).
In general this should work for now until we deside to support this opt.
Differential revision: https://reviews.llvm.org/D19663
llvm-svn: 276323
We no longer need it for relocations in .eh_frame.
The only relocations that point to .eh_frame are the ones trying to
find the output .eh_frame.
This actually fixes a bug in the symbol value code. It was not
handling -1 as an indicator for a piece not being included in the
output.
llvm-svn: 276175
LLD still does not produce a correct combination of MIPS ELF flags if
input files have different sets of ELF flags (i.e. EF_MIPS_ARCH_32 and
EF_MIPS_ARCH_32R2). But now we do not stick to "R2" ABI version and can
emit EF_MIPS_ARCH_32R6 for example.
llvm-svn: 276172
- R_ARM_TLS_LDM32
- R_ARM_TLS_LDO32
The local dynamic implementation and tests follows the same model as
the other ARM TLS models. The R_ARM_TLS_LDO32 is implemented as R_ABS
expr type as the getVA() for a TLS symbol will return the offset from the
start of the TLS block.
Differential Revision https://reviews.llvm.org/D22563
llvm-svn: 276123
Add relocations and identification functions for the Initial Exec
and Global Dynamic TLS model defined in Addenda to, and Errata in,
the ABI for the ARM Architecture.
ARM uses variant 1 of the thread local storage data
structures as defined in ELF Handling for Thread-Local Storage.
The "experimental" descriptor based model that can be selected in
gcc, but not clang with -mtls-dialect=gnu2 is not supported.
The relocations R_ARM_TLS_LE12 and R_ARM_TLS_IE12GP are not
supported, I know of no ARM Toolchain that supports these relocations
as they limit the size of the TLS block.
No code relaxation is supported as the standard ARM TLS model puts
the relocations on literal data.
Support for the local dynamic model will come in a follow up patch.
Differential Revision: https://reviews.llvm.org/D22462
llvm-svn: 276095
--trace-symbol is a command line option to watch a symbol.
Previosly, we looked up a hash table for a new symbol if the
option is given. Any code that looks up a hash table for each
symbol is expensive because the linker handles a lot of symbols.
In our design, we look up a hash table strictly only once
for a symbol, so --trace-symbol was an exception.
This patch improves efficiency of the option by merging the
hash table into the symbol table.
Instead of looking up a separate hash table with a string,
this patch sets `Traced` flag to symbols specified by --trace-symbol.
So, if you insert a symbol and get a symbol with `Traced` flag on,
you know that you need to print out a log message for the symbol.
This is nearly zero cost.
llvm-svn: 275716
Versions can be assigned to symbols in two different ways.
One is the usual version scripts, and the other is special
symbol suffix '@'. If a symbol contains '@', the string after
that is considered to specify a version name.
Previously, we look for '@' for all symbols.
Anything that works on every symbol can be expensive because
the linker has to handle a lot of symbols. The search for '@'
was not an exception.
In this patch, I made two optimizations.
The first optimization is to handle '@' only when at least one
version is defined. If no versions are defined, no versions can
be assigned to any symbols, so it's waste of time to search for '@'.
The second optimization is to scan only suffixes of symbol names
instead of entire symbol names. Symbol names can be very long, but
symbol versions are usually short, so scanning entire symbol names
is waste of time, too.
There are some error cases which we no longer be able to detect
with this patch. I don't think it's a major drawback because they
are minor errors. Speed is more important.
This change improves LLD with debug info self-link time from
6.6993 seconds to 6.3426 seconds (or -5.3%).
Differential Revision: https://reviews.llvm.org/D22433
llvm-svn: 275711
ELF spec says that alignment of 0 is equivalent to 1.
Previously, we arbitrary set to 0 or 1, but always setting to 1
makes our program simpler.
llvm-svn: 275374
This is to follow the convention of naming the test after the name
of the option.
Differential Revision: http://reviews.llvm.org/D22276
llvm-svn: 275295
Patch implements 'extern' version script tag.
Currently only values in quotes(") are supported.
Matching of externs is performed in the same pass as exact match of globals.
Differential revision: http://reviews.llvm.org/D21930
llvm-svn: 275257
Patch by H.J. Lu.
This patch adds -m elf32_x86_64 to lld. But it doesn't generate working
x32 binaries.
Differential Revision: http://reviews.llvm.org/D22268
llvm-svn: 275236
The TinyPtrVector of const Thunk<ELFT>* in InputSections.h can cause
build failures on certain compiler/library combinations when Thunk<ELFT>
is not a complete type or is an abstract class. Fixed by making Thunk<ELFT>
non Abstract.
type or is an abstract class
llvm-svn: 274863
Generalise the Mips LA25 Thunk code and implement ARM and Thumb
interworking Thunks.
- Introduce a new module Thunks.cpp to store the Target Specific Thunk
implementations.
- DefinedRegular and Shared have a ThunkData field to record Thunk.
- A Target can have more than one type of Thunk.
- Support PC-relative calls to Thunks.
- Support Thunks to PLT entries.
- Existing Mips LA25 Thunk code integrated.
- Support for ARMv7A interworking Thunks.
Limitations:
- Only one Thunk per SymbolBody, this is sufficient for all currently
implemented Thunks.
- ARM thunks assume presence of V6T2 MOVT and MOVW instructions.
Differential revision: http://reviews.llvm.org/D21891
llvm-svn: 274836
When building executable usually version script is absent.
Before this patch error was shown in the case when
symbol name contained version and there was no script to match it.
Instead of error out patch allows
to create new version declaration in this case and use it.
gnu linkers do the same.
That is PR28359.
Differential revision: http://reviews.llvm.org/D21890
llvm-svn: 274828
Previously, it was not tested because the test was written in
a way that it passed on a platform that does not support
abi::__cxa_demangle. Now we restrict this test to Unix (by adding
"REQUIRES: shell") and assume that it always demangle symbols.
Thanks to Davide to find out the issue.
llvm-svn: 274808
Previously we had incorrect logic here. Imagine we would have the next script:
LIBSAMPLE_1.0
{
global:
a_2;
local:
*;
};
LIBSAMPLE_2.0
{
global:
a*;
};
According to previous logic it would assign version 1 to a_2 and then
would try to reassign it to version 2 because of applying wildcard a*.
And show a warning about that.
Generally Ian Lance Tailor wrote about next rules that should be applied:
(http://www.airs.com/blog/archives/300)
Here are the current rules for gold:
"If there is an exact match for the mangled name, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error.
Otherwise, we look for an extern C++ or an extern Java exact match. If we find an exact match, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error.
Otherwise, we look through the wildcard patterns, ignoring “*” patterns. We look through the version tags in reverse order. For each version tag, we look through the global patterns and then the local patterns. We use the first match we find (i.e., the last matching version tag in the file).
Otherwise, we use the “*” pattern if there is one. We give a warning if there are multiple “*” patterns."
Patch makes wildcard matching to be in revered order and to follow after the regular naming matching.
Differential revision: http://reviews.llvm.org/D21894
llvm-svn: 274739
Previously, ch_size was read in host byte order, so if a host and
a target are different in byte order, we would produce a corrupted
output.
llvm-svn: 274729
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
These references are used to implement MachO/x64-64 subtractor relocations
where the minuend is being fixed up, rather than the subtrahend. The 64-bit
version was not previously supported, the 32-bit version was partially
implemented but contained bugs not caught by existing test cases. This
patch fixes both functionality and test coverage.
llvm-svn: 273759
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
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
Patch implements next relaxation from latest ABI:
"Convert memory operand of test and binop into immediate operand, where binop is one of adc, add, and, cmp, or,
sbb, sub, xor instructions, when position-independent code is disabled."
It is described in System V Application Binary Interface AMD64 Architecture Processor
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf,
B.2 "B.2 Optimize GOTPCRELX Relocations").
Differential revision: http://reviews.llvm.org/D20793
llvm-svn: 271405
When we undefine, we also preserve type of symbol so that we get
it right in the combined LTO object.
Differential Revision: http://reviews.llvm.org/D20851
llvm-svn: 271403
In case of MIPS, GP-relative relocations always resolve to a definition
in a regular input file, ignoring the one-definition rule. Such
relocations are used to setup GP relative offsets in a function's
prologue. So we, for example, should not attempt to create a dynamic
relocation even if the target symbol is preemptible.
Fixes bug 27880.
Differential Revision: http://reviews.llvm.org/D20664
llvm-svn: 271100
MIPS .reginfo and .MIPS.options sections are consumed by the linker, and
the linker produces a single output section. But it is possible that
input files contain section symbol points to the corresponding input
section. In case of generation a relocatable output we need to write
such symbols to the output file.
Fixes bug 27878.
Differential Revision: http://reviews.llvm.org/D20688
llvm-svn: 270910
D15779 introduced basic approach to support new relaxations.
This patch implements relaxations for jmp and call instructions,
described in System V Application Binary Interface AMD64 Architecture Processor
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf,
B.2 "B.2 Optimize GOTPCRELX Relocations")
Differential revision: http://reviews.llvm.org/D20622
llvm-svn: 270721
Add another possible error that may be reported for the same case. The
original reproduction case that prompted r270706 produced the error
"corrupted CIE" instead of "corrupted or unsupported CIE information".
The specific error depends on arbitrary data later in the file so
check that neither is emitted in case the input is ever changed.
Document the process used to create the input .o and rename the test
file to .s, as requested by Rafael.
llvm-svn: 270709
"A zero length string indicates that no augmentation data is present."
The FreeBSD/mips toolchain (GCC 4.2.1) generates .debug_frame sections
containing CIE records that have an empty augmentation string.
Differential Revision: http://reviews.llvm.org/D19928
llvm-svn: 270706
System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8
(https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations")
introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.
That patch implements the next relaxation:
mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg
and also opens door for implementing all other ones.
Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself.
Differential revision: http://reviews.llvm.org/D15779
llvm-svn: 270705
Previously, we created a .bss section when needed. We had a function
ensureBss() for that purpose. Turned out that was error-prone
because it was easy to forget to call that function before accessing
the .bss section.
This patch always make the BSS section. The section is added to the
output when it's not empty.
llvm-svn: 270527
Copy relocations are relocations to copy data from DSOs to
executable's .bss segment at runtime. It doesn't make sense to
create such relocations for zero-sized symbols.
GNU linkers don't agree with each other. ld rejects such
relocation/symbol pair. gold don't reject that but do not create
copy relocations as well. I took the former approach because
I don't think the latter is what user wants.
llvm-svn: 270525
Previously, EhFrameHdr section computed addresses to which FDEs are
applied to. This is not an ideal design because EhFrameHdr does not
know much about FDEs unless EhFrame passes the information to EhFrameHdr.
It is what we did.
This patch simplifies the code by making EhFrame to compute the
values and pass the cooked information to EhFrameHdr. EhFrameHdr no
longer have to know about the details of FDEs such as FDE encodings.
llvm-svn: 270393
This patch refactors EHOutputSection using SectionPiece struct.
EHRegion class was removed since we can now directly use SectionPiece.
An incomplete support of large CIE/FDE record (> 2^32 bytes) was removed
because it silently created broken executable. There are several places
in the existing code that "size" field is always 4 bytes and at offset 4
in the record, which is not true for 64-bit size records. We will have to
support that in future, but it is better to error out instead of creating
malformed eh_frame sections.
llvm-svn: 270382
the linker script. The cycle in the ELF/LinkerScript.cpp:assignAddresses()
routine will be used to go through all the sections and set all the
addresses correctly.
Add new test to check this case.
llvm-svn: 270090
Lazy binding is quite important for use case like a shared build of
llvm. Also, if someone wants to disable it, it is better done in the
compiler (disable plt generation).
The only reason to keep it is to make it easier to add a new
architecture. But it doesn't really help much as it is possible to start
with non lazy relocation and plt code but still let the generic part
create a dedicated .got.plt and .rela.plt.
llvm-svn: 269982
George Rimar