One reason why we are (ab)using OutputSectionFactory class is
because it owns output sections. Technically there's no need
to have it own sections. So, this patch transfers the ownership
to Out<ELFT>.
llvm-svn: 278452
The reason why we had to assign offsets only to sections that
don't contain layout sections were unclear. It turned out that
we can live without it.
llvm-svn: 278449
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
Reorder the table setup to mirror the indices corresponding to them. This means
that the table values are filled out as per the enumeration ordering. Doing so
makes it easier to identify a particular table. NFC.
llvm-svn: 278199
Even if an output is not a dynamic object, the output may have
.{preinit,init,fini} sections. Therefore, managing these sections
as Out<ELFT>::Dynamic's members is not correct.
llvm-svn: 278093
The Factory class is too object-oriented-ish and easy to be abused.
This patch reduces dependency to that class. Eventually we want to
remove the dependency to that class from LinkerScript.
llvm-svn: 278084
Add the support infrastructure for the /debugtype option which takes a comma
delimited list of debug info to generate. The defaults are based on other
options potentially (/driver or /profile). This sets up the infrastructure to
allow us to emit RSDS records to get "build id" equivalents on COFF (similar to
binutils).
llvm-svn: 278056
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
Summary:
The comparator function to compare input sections as instructed by
SORT command was a bit too complicated because it needed to handle
four different cases. This patch split it into two function calls.
This patch also simplifies the parser.
Reviewers: grimar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23140
llvm-svn: 277780
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, many read* functions created new command objects and
add them directly to the top-level data structure. This is not
work for some commands because some commands, such as the assignment,
can appear inside and outside of the output section description.
This patch is to not append objects to the top-level data structure.
Callers are now responsible to do that.
llvm-svn: 277686
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
The MachO debug support code (committed in r276935) occasionally needs to
allocate string copies, and was doing so by creating std::strings on a
BumpPtrAllocator. The strings were untracked, so the destructors weren't being
run and we were leaking the memory when the allocator was thrown away. Since
it's easier than tracking the strings, this patch switches the copies to char
buffers allocated directly in the bump-ptr allocator.
llvm-svn: 277208
Previously, Ignore flag is set if we don't want to assign
a value to symbols. It happens if a symbol assingment is in
PROVIDE() and there's already a symbol with the same name.
The previous code had a subtle but that we assume that the
existing symbol is an absolute symbol even if it is not.
This patch fixes the issue by always overwriting an absolute
symbol.
llvm-svn: 277115
According to the specification, CIE code alignment factor is an
arbitrary unsigned LEB128 encoded value.
Differential revision: https://reviews.llvm.org/D22954
llvm-svn: 277105
All other singleton instances are accessible globally.
CommonInputSection shouldn't be an exception.
Differential Revision: https://reviews.llvm.org/D22935
llvm-svn: 277034
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
We already have code for ARM in initializeSections, so this
is more consistent.
Differential Revision: https://reviews.llvm.org/D22833
llvm-svn: 276811
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
This enables proper recognition of debug sections by attribute, which will be
used in the near future by test-cases for MachO debugging support.
llvm-svn: 276770
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
We can have Opt.Commands size greater then Sections.size().
For example if we have next script:
SECTIONS {
.aaa : { *(.aaa) }
.bbb : { *(.bbb) }
.ccc : { *(.ccc) }
}
and next code:
.global _start
_start:
nop
.section .aaa,"a"
.quad 0
Then amount of sections is less than amound of Opt.Commands
and if we for example have all commands NoConstraint,
that overflowed the iterator used.
llvm-svn: 276741
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
createSections function is getting longer, so it is time to split it
into small functions. The reason why the function is long is because
it has deeply nested for-loops. This patch constructs temporary data
to reduce nesting level.
Differential Revision: https://reviews.llvm.org/D22786
llvm-svn: 276706
match() returns true of the first argument, a target string, matches
one of the second argument, a list of glob patterns. Calling the
target string, which is not a glob pattern, "Pattern" was very confusing.
llvm-svn: 276705
This will grow because I have a patch to support more complex
constructs, e.g.:
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
Let's make this a separate function.
llvm-svn: 276695
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
It doesn't appear to like this pattern:
for (auto X : Xs)
if (...) { ... }
else ...;
We have heard anecdotes that range based for loops are implemented as a
token rewrite in MSVC's lexer, and that the most challenging part of the
rewrite is finding the end of the for loop. That makes sense, given that
it's a lexer.
llvm-svn: 276315
LinkerScript<ELFT>::assignAddresses is becoming larger and looks
it can be good time for splitting. I expect to can more SectionsCommand's there,
and dispatching some of them separatelly can help to keep method smaller either.
Differential revision: https://reviews.llvm.org/D22506
llvm-svn: 276300
Had 3 testcases failtures:
ELF/eh-frame-merge.s
ELF/gc-sections-eh.s
ELF/gc-sections-lsda.s
Problem was that OutputOff is size_t, which is 32
for this configuration and next
condition never was checked correctly:
if (PieceI->OutputOff == (uintX_t)-1)
continue;
llvm-svn: 276296
This adds InputSectionDescription command to represent
the input section declaration.
This leads to next cleanup:
SectionRule removed.
ScriptConfiguration::Sections mamber removed.
LinkerScript<ELFT>::getOutputSection() removed.
Differential revision: https://reviews.llvm.org/D22617
llvm-svn: 276283
r275711 for "speedng up symbol version handling" was committed
by misunderstanding; the benchmark number was measured with
a debug build. The number with a release build didn't actually change.
This patch removes false optimizations added in that patch.
llvm-svn: 276267
This change simplifies interaction between Writer and the linker script
because we can make needsInterpSection() a file-scope function.
llvm-svn: 276261
Approach uses LLVM-style RTTI for representing the linker script
commands in a form of tree for future simplification of parsing.
Core idea and code sample belongs to Rui Ueyama.
Differential revision: https://reviews.llvm.org/D22604
llvm-svn: 276243
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
We will need to do something like this to support range extension
thunks since that process is iterative.
Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.
By itself this is already a performance win.
firefox
master 7.295045737
patch 7.209466989 0.98826892235
chromium
master 4.531254468
patch 4.509221804 0.995137623774
chromium fast
master 1.836928973
patch 1.823805241 0.992855612714
the gold plugin
master 0.379768791
patch 0.380043405 1.00072310839
clang
master 0.642698284
patch 0.642215663 0.999249070657
llvm-as
master 0.036665467
patch 0.036456225 0.994293213284
the gold plugin fsds
master 0.40395817
patch 0.404384555 1.0010555177
clang fsds
master 0.722045545
patch 0.720946135 0.998477367518
llvm-as fsds
master 0.03292646
patch 0.032759965 0.994943428477
scylla
master 3.427376378
patch 3.368316181 0.98276810292
llvm-svn: 276146
This patch simplifies output section management by making
Factory class have ownership of sections that creates.
Differential Revision: https://reviews.llvm.org/D22575
llvm-svn: 276141
Previously it was harder to read and also has a error:
command kind was not checked.
Differential revision: https://reviews.llvm.org/D22574
llvm-svn: 276137
- 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
Under MSVS 2015 I observed integral constant overflow warning when aggregate initialization was used
to init the bit field. Patch fixes that.
llvm-svn: 276118
In here we are iterating relocations in order, so we can do the same
with the pieces of .eh_frame and avoid a binary search.
The link times I got with this patch were:
firefox
master 7.22977811
patch 7.141041442 0.987726225252
chromium
master 4.478966851
patch 4.506602207 1.00617002914
chromium fast
master 1.894713371
patch 1.866446889 0.98508139414
the gold plugin
master 0.386193907
patch 0.382374918 0.990111213743
clang
master 0.654849589
patch 0.647899815 0.989387220949
llvm-as
master 0.037212718
patch 0.036858172 0.990472450843
the gold plugin fsds
master 0.410876711
patch 0.407418613 0.991583611562
clang fsds
master 0.734623069
patch 0.728237526 0.991307728726
llvm-as fsds
master 0.033446197
patch 0.03302833 0.987506292569
scylla
master 3.38134402
patch 3.414188846 1.00971354166
llvm-svn: 276108
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
In the last patch for --trace-symbol, I introduced a new symbol type
PlaceholderKind and store it to SymVector storage. It made all code
that iterates over SymVector to recognize and skip PlaceholderKind
symbols. I found that that's annoying.
In this patch, I removed PlaceholderKind and stop storing them to SymVector.
Now the information whether a symbol is being watched by --trace-symbol
is stored to the Symtab hash table.
llvm-svn: 275747
SymVector contains all symbols, so we can iterate either Symtab or SymVector
to visit all symbols. Iterating over SymVector makes the next change for
--trace-symbol possible.
llvm-svn: 275746
--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
Previously, each subclass of SymbolBody had a pointer to a source
file from which it was created. So, there was no single way to get
a source file for a symbol. We had getSourceFile<ELFT>(), but the
function was a bit inconvenient as it's a template.
This patch makes SymbolBody have a pointer to a source file.
If a symbol is not created from a file, the pointer has a nullptr.
llvm-svn: 275701
The identifier `Version` was used too often in the code to handle
symbol versions. The struct that contains version definitions is
named `Version`. Local variables for version ID are named `Version`.
Local varaible for version string are named `Version`.
This patch give them different names.
llvm-svn: 275673
Previously, Verdefs and Verdauxs are separated in the section.
The new layout is easier to write as we do not have to maintain
two pointers and can avoid passing a reference to a pointer.
llvm-svn: 275665
Rui Ueyama