od is defined by POSIX and exists since version 1 AT&T Unix.
hexdump is not part of any standard as far as I know.
So od is a better choice than hexdump.
Differential Revision: https://reviews.llvm.org/D24205
llvm-svn: 280536
Windows does not allow opened files to be removed. This patch
fixes two types of errors.
- Output file being the same as input file. Because LLD itself
holds a file descriptor of the input file, it cannot create an
output file with the same name as a new file.
- Removing files before releasing MemoryBuffer objects.
These tests are not failing no because MemoryBuffer happens to
decide not to use mmap on these files. But we shouldn't rely on
that behavior.
llvm-svn: 280507
Both bfd and gold accept:
foo = 1K;
bar = 1M;
zed = 1H;
And lowercase forms: k, m, h.
Patch adds support for that.
Differential revision: https://reviews.llvm.org/D24194
llvm-svn: 280494
FreeBSD's libstdc++ build (used on tier-2 architectures) uses GNU ld's
-f <name> option, which sets the DT_AUXILIARY field to the specified name.
Multiple -f options may be specified and the DT_AUXILIARY entries
will be added in the order in which they appear.
Patch implements that option.
Differential revision: https://reviews.llvm.org/D24139
llvm-svn: 280475
This is what InputSectionBase<ELFT>::relocate does and we need to be
consistent. The other option would be to be more explicit about which
relocations are signed and which are not, and sign extend only when
appropriated. That would require extending the target interface.
llvm-svn: 280366
Summary:
VERSION commands define symbol versions. The grammar of the
commnad is as follows
VERSION { version-script-commands }
where version-script-commands is
[ name ] { version-definitions }.
Note that we already support version-script-commands because
it is being used for version script command.
This patch is based on George's patch https://reviews.llvm.org/D23609
Reviewers: grimar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24089
llvm-svn: 280284
Symbol assignments outside of SECTIONS command need to be created
even when SECTIONS command is not used.
Differential Revision: https://reviews.llvm.org/D23751
llvm-svn: 280252
Before this lld was always creating common symbols itself. It worked,
but prevented them from being internalized when possible.
Now it preserves common symbols is the bitcode and they are internalized.
Fixes pr30184.
llvm-svn: 280242
As stated in PR28843:
we should handle command lines with
-target1-rel -target1-abs
--demangle --no-demangle
Patch implements this for specified options.
There are probably other conflicting options can exist,
so fix is called "partial".
Differential revision: https://reviews.llvm.org/D23867
llvm-svn: 280211
This patch groups relative relocations in a single block
in combrelocs mode and adds DT_RELCOUNT or DT_RELACOUNT
tag to .dynamic section
Differential revision: https://reviews.llvm.org/D23661
llvm-svn: 280210
Allows adding start and/or end symbols to special output sections,
like .eh_frame_hdr, which aren't lists of regular input sections.
Differential revision: https://reviews.llvm.org/D23716
llvm-svn: 280205
FreeBSD/mips script has non-wildcard filename specifications:
.text :
{
start.o(.text*)
Patch adds support for that, this is PR29115.
Differential revision: https://reviews.llvm.org/D23839
llvm-svn: 280069
Previously for extern keyword only names in quotes (exact match) was supported.
Patch adds support for wildcards, so next scripts can be handled properly:
LIBSAMPLE_1.0 {
global:
extern "C++" {
foo*;
};
};
Differential revision: https://reviews.llvm.org/D23794
llvm-svn: 280067
GNU gold handles output section fillers as 32-bit values.
This patch makes LLD compatible with that behavior.
Differential revision: https://reviews.llvm.org/D23181
llvm-svn: 280018
The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of
COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF
Debug Directory. These OMF debug directories are derived into newer types such
as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to
associate a GUID with a build to actually tie debug information.
llvm-svn: 280012
-oformat output-format
`-oformat' option can be used to specify the binary format for the output object file.
Patch implements binary format output type.
Differential revision: https://reviews.llvm.org/D23769
llvm-svn: 279726
The ARM Exception handling ABI requires that all ARM exception index
table sections have a prefix of .ARM.exidx and are combined into a
single contiguous block either in their own output section or as part
of another output section.
In general clang will output a single .ARM.exidx section per object,
but will use .ARM.exidx.<section name> when -ffunction-sections is used.
This change canonicalizes the names of sections with the .ARM.exidx
prefix to just .ARM.exidx, which ensures that there is only a single
output section.
Differential Revision: https://reviews.llvm.org/D23775
llvm-svn: 279617
Not only symbols (like sections) have names, in case where we
fail to create relocation against such symbol, we should not
print out an empty string, instead we should print a generic
message.
Differential Revision: https://reviews.llvm.org/D23731
llvm-svn: 279459
When performing ICF, we have to respect the alignment requirement
of each section within each group.
Differential Revision: https://reviews.llvm.org/D23732
llvm-svn: 279456
TLS on i386 in non-PIE/PIC code seems broken right now, because we don't
properly add the addend encoded in the instruction to the resulting
offset when processing R_386_TLS_LE relocations.
Extend one of the existing tests for TLS on i686 to use an addend.
PR: https://llvm.org/bugs/show_bug.cgi?id=29068
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D23741
llvm-svn: 279368
This is fix for PR28976.
Problem was that in scanRelocs, we computed relocation offset too early
for case when linkerscript was used. Patch fixes the issue
delaying the calculation.
Differential revision: https://reviews.llvm.org/D23655
llvm-svn: 279264
This patch is opposite to D19024, which made this symbols to be hidden by default.
Unfortunately FreeBSD loader wants to see
start_set_modmetadata_set/stop_set_modmetadata_set in the dynamic symbol table.
They were not placed there because had hidden visibility.
Patch makes them to have default visibility again.
Differential revision: https://reviews.llvm.org/D23552
llvm-svn: 279262
Previously DT_PREINIT_ARRAYSZ, DT_INIT_ARRAYSZ and DT_FINI_ARRAYSZ
were set to zero when lincerscript was used becase sections sizes are
calculated later that were taken.
Patch delays values calculation for these entries. Testcase is provided.
Differential revision: https://reviews.llvm.org/D23663
llvm-svn: 279258
You can force input section alignment within an output section by using SUBALIGN. The
value specified overrides any alignment given by input sections, whether larger or smaller.
SUBALIGN is used in many projects in the wild.
Differential revision: https://reviews.llvm.org/D23063
llvm-svn: 279256
Spec says "A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object".
But we previously converted symbols to STB_LOCAL even when -r was specified.
Broken binary was produced, this is PR28967, patch fixes the issue.
Differential revision: https://reviews.llvm.org/D23514
llvm-svn: 279220
We should always include symbol name when reporting relocations
error to simplify debugging of these issues. Without symbol names
users have to manually investigate which of the libraries contain
invalid relocations which can be cumbersome when linking multiple
libraries.
Differential Revision: https://reviews.llvm.org/D23690
llvm-svn: 279162
We only support assignments inside SECTIONS, but this does not match
the behavior of GNU linker which also allows them outside SECTIONS.
The only restriction on assignments outside SECTIONS is that they
cannot reference . (they have to be absolute expressions).
Differential Revision: https://reviews.llvm.org/D23598
llvm-svn: 279033
The linker will normally set the LMA equal to the VMA.
You can change that by using the AT keyword.
The expression lma that follows the AT keyword specifies
the load address of the section.
Patch implements this keyword.
Differential revision: https://reviews.llvm.org/D19272
llvm-svn: 278911
This add support for HIDDEN command which can be used to define
a symbol that will be hidden and won't be exported.
Differential Revision: https://reviews.llvm.org/D23534
llvm-svn: 278770
Previously we searched output section by name to assign VA. That did not
work in the case when multiple output sections with different constraints were defined in script.
Testcase shows the possible issue scenario, patch fixes the issue.
Differential revision: https://reviews.llvm.org/D23451
llvm-svn: 278561
After latest changes we combine input sections with
different attributes into single output section.
Problem here is that regular output sections does not
support adding mergeable input sections (and vise versa).
Patch just temporarily disables merging for now at
the same way we do for -O0 for example.
This change helps for linking FreeBSD kernel.
Differential revision: https://reviews.llvm.org/D23447
llvm-svn: 278555
We found that GNU assembler 2.17.50 [FreeBSD] 2007-07-03
could generate broken objects. STT_SECTION symbols can be
associated with SHT_REL[A]/SHT_SYMTAB/SHT_STRTAB sections.
This is PR28868, patch fixes handling of such files.
Differential revision: https://reviews.llvm.org/D23201
llvm-svn: 278550
Previously filtering that was used worked incorrectly.
For example for next script it would just remove both sections completely:
SECTIONS {
. = 0x1000;
.aaa : ONLY_IF_RW { *(.aaa.*) }
. = 0x2000;
.aaa : ONLY_IF_RO { *(.aaa.*) }
}
Patch fixes above issues and adds testcase showing the issue. Testcase is a subset of
FreeBSD script which has:
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
...
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
Differential revision: https://reviews.llvm.org/D23326
llvm-svn: 278486
This section supersedes .reginfo and .MIPS.options sections. But for now
we have to support all three sections for ABI transition period.
llvm-svn: 278482
Previously, we created two or more output sections if there are
input sections with the same name but with different attributes.
That is a wrong behavior. This patch fixes the issue.
One thing we need to do is to merge output section attributes.
Currently, we create an output section based on the first input
section's attributes. This may make a wrong output section
attributes. What we need to do is to bitwise-OR attributes.
We'll do it in a follow-up patch.
llvm-svn: 278461
It only makes sense to set on N_NO_DEAD_STRIP on a relocatable object file. Otherwise the bits aren't useful for anything. Matches the ld64 behaviour.
llvm-svn: 278419
We should be using one of BIND_OPCODE_SET_DYLIB_SPECIAL_IMM, BIND_OPCODE_SET_DYLIB_ORDINAL_IMM,
and BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB depending on whether ordinals are <= 0, <= 15, > 15.
This matches the behaviour of ld64.
llvm-svn: 278407
We already had logic for binding opcodes had the same addend as last time. This adds
the cases where the ordinal, symbol name, type, and segment offsets are the same as
the last emitted ordinal.
This gets us one step closer to emitting rebase opcodes as compressed as ld64 can manage.
llvm-svn: 278405
Currently we do this when an atom is used, but we need to do it when a
dylib is referenced on the cmdline as this matches ld64.
This fixes much confusion over which maps are indexed with installName
vs path. There is likely other confusion so i'll be seeing if i can remove
path() completely in a future commit as path() shouldn't really be needed by anyone.
llvm-svn: 278396
A future commit will change when we choose to add an LC_LOAD_DYLIB to the final image. Currently
we do this when an atom is used, but we need to do it when a dylib is referenced on the cmdline as
this matches ld64.
To allow this change, libsystem (and other future yaml files representing dylibs) need to be dylibs
so that the loader can see to add them to the referenced dylib list.
llvm-svn: 278386
A version of 0x1000 is 0.16.0, not 1.0.0 as the comment said. Fix the
value to match the comment, and also the one test case which had this
wrong.
llvm-svn: 278381
An upcoming commit will change how we choose to reference a dylib. Currently
dylibs are only given an LC_LOAD_DYLIB in the final image if an atom is used.
This is different from ld64 which adds the load command when the dylib is referenced
on the cmdline.
In order to change this behaviour, we need libSystem.yaml to actually contain a mach header
so that it is parsed as a dylib, instead of currently being parsed as a normalised file.
To get a mach header, we also require an arch, so now we have one libsystem per arch and
all the tests have been updated to choose the correct one.
llvm-svn: 278372
Using vmsize to populate this file works when outputing MachO images, but fails
when outputting relocatable objects. This patch fixes the computation to use
file offsets, which works for both output types.
Fixes <rdar://problem/27727666>
llvm-svn: 278297
MIPS ISA encoded using two ELF flags: general architecture flag like
EF_MIPS_ARCH_32, EF_MIPS_ARCH_64R6 etc and optional machine variant flag
like EF_MIPS_MACH_4111, EF_MIPS_MACH_OCTEON3 etc. When we check
compatibility between two input files and deduce ELF flags for generated
output we need to take into account both of these flags.
llvm-svn: 278230
SIZEOF_HEADERS - Return the size in bytes of the output file’s headers.
It is is a feature used in FreeBsd script, for example.
There is a discussion on PR28688 page about it.
Differential revision: https://reviews.llvm.org/D23165
llvm-svn: 278204
Previously, we incrementally updated the reuslting flag as we check
file flags, so it was not very clear who is updating what flags.
This patch makes them pure functions -- that has no side effect and
don't update arguments to improve readability.
Now each function construct a patial result, and all resutls are then
bitwise-OR'ed to construct the final result.
This patch also creates a new file, Mips.cpp, to move all these
MIPS functions to a separate file.
Differential Revision: https://reviews.llvm.org/D23249
llvm-svn: 278042
I faced that when tried to link FreeBSD kernel.
It was "duplicate symbol: _edata in (internal) and (internal)" error.
_data was a shared symbol that came from hack.so. At first it was replaced with DefinedRegular by the code
disabled in this patch and later when script tried to define the same symbol - the error was shown.
In the same situation (as given in testcase) ld defines them as UND. gold defines as ABS with zero value.
Patch just disables any operations of creating these symbols if script do layout.
Differential revision: https://reviews.llvm.org/D23206
llvm-svn: 277986
The patch extends the `getMipsEFlags` function. Now in that function
we iterate over all object files, parse ELF header flags and merge them.
If a file is incompatible with previously analyzed ones we show an error
or warning. That can happen if, for example, we try to link files with
incompatible ABI, ISA, NAN encoding etc.
There is an alternative solution. We can check and merge flags and
reject incompatible input modules in the `isCompatible` function which
is called from the `SymbolTable::addFile` method. But in that case we
have to save and keep somewhere a merged ELF flags combination to use it
later in the writer.
Differential Revision: http://reviews.llvm.org/D23161
llvm-svn: 277911
The export trie was being emitted in the order the nodes were
added to the vector, but instead needs to be visited in the order
that the nodes are traversed. This matches the behaviour of ld64.
llvm-svn: 277869
Don't blindly OR in the new value, but clear the existing one, since it can be
nonzero. Read out the existing value before, and add into the desired offset.
(The add is done outside of the applyMOV, to handle potential overflow between
the two.)
Patch by Martin Storsjö!
llvm-svn: 277846
The opcode for the bl branches can initially be F000 F800, i.e.
the J1 and J2 bits are already set. Therefore mask these bits out
before or'ing in the new bits.
Patch by Martin Storsjö!
llvm-svn: 277836
ASSERT(exp, message)
Ensure that exp is non-zero. If it is zero, then exit the linker with an error
code, and print message.
ASSERT is useful and was seen in few projects in the wild.
Differential revision: https://reviews.llvm.org/D22912
llvm-svn: 277710
According to spec:
"SORT_BY_ALIGNMENT will sort sections into descending order by
alignment before placing them in the output file"
Previously they were sorted into ascending order.
llvm-svn: 277706
With the previous change, it is now obvious that readProvide in
this context appended new commands to a wrong command list.
It was mistakenly adding new commands to the top level.
Thus, all commands inside output section descriptions were
interpreted as they were written on top level.
PROVIDE command naturally requires symbol assignment support
in the output section description. We don't have that one yet.
I removed the implementation because there's no way to fix it now.
We can resurrect the test once we support the symbol assignment
(with a modification to detect errors that we failed to find as
described.)
llvm-svn: 277687
Previously, a decimal filler expression is interpreted as a byte value.
Gold on the other hand use it as a 32-bit big-endian value.
This patch fixes the compatibility issue.
Differential Revision: https://reviews.llvm.org/D23142
llvm-svn: 277680
Previously we supported only sorting by name.
When there are nested section sorting commands in linker script, there can be at most 1
level of nesting for section sorting commands.
SORT_BY_NAME (SORT_BY_ALIGNMENT (wildcard section pattern)). It will sort the input
sections by name first, then by alignment if 2 sections have the same name.
SORT_BY_ALIGNMENT (SORT_BY_NAME (wildcard section pattern)). It will sort the input
sections by alignment first, then by name if 2 sections have the same alignment.
SORT_BY_NAME (SORT_BY_NAME (wildcard section pattern)) is treated the same as SORT_
BY_NAME (wildcard section pattern).
SORT_BY_ALIGNMENT (SORT_BY_ALIGNMENT (wildcard section pattern)) is treated the
same as SORT_BY_ALIGNMENT (wildcard section pattern).
All other nested section sorting commands are invalid.
Patch implements that all above.
Differential revision: https://reviews.llvm.org/D23019
llvm-svn: 277583
Mergeable sections with size zero are useless because they don't
actually contain data, and therefore there's no merit ot merge them.
However, in reality, there are object files in the wild containing
such sections. Currently, LLD can't handle them proerply.
This patch makes LLD to handle such sections as if they are non-
mergeable to fix the issue.
Fixes bug 28822.
llvm-svn: 277568
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
Rui Ueyama