That allows to detemplate getGotPltOffset/getGotPltVA
methods of SymbolBody and also will help to detemplate
DynamicReloc itself later.
llvm-svn: 297946
Patch splits In<ELFT> into 2 classes: one for non-templated sections,
second contains ELFT templated ones.
That allows to code that was detemplated to access non-templated sections freely,
and should open road for futher detemplation proccess.
Differential revision: https://reviews.llvm.org/D30939
llvm-svn: 297844
After introducing Config->is64Bit() and
recent changes in LinkerScriptBase, some
sections can be detemplated trivially. This
is one of such cases.
llvm-svn: 297825
StringTableSection was <ELFT> templated previously,
It disallow to de-template code that uses it,
for example LinkerScript<ELFT>::discard uses it as:
if (S == In<ELFT>::ShStrTab)
error("discarding .shstrtab section is not allowed");
It seems we can try to detemplate some of synthetic sections
and somehow make them available for non-templated calls.
(move out of In<ELFT> struct probably).
Differential revision: https://reviews.llvm.org/D30933
llvm-svn: 297815
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 297814
Patch introduces Config->is64Bit() and with help of that detemplates
GotPltSection and IgotPltSection sections
Differential revision: https://reviews.llvm.org/D30944
llvm-svn: 297813
This also requires postponing the assignment the assignment of
symbols defined in input linker scripts since those can refer to
output sections and in case we don't have a SECTIONS command, we
need to wait until all output sections have been created and
assigned addresses.
Differential Revision: https://reviews.llvm.org/D30851
llvm-svn: 297802
Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.
llvm-svn: 297789
That moves all members that s possible to move for now (all which
does not depend on ELFT templating).
After that change LinkerScript contains only 8 methods in total,
and I believe it is possible to move them all after tweaking other
parts of linker. And we will be able to have single class for
linkerscript at the end.
llvm-svn: 297735
We can move all not templated functionality to LinkerScriptBase.
Patch do that for hasPhdrsCommands() and shows how it helps to detemplate
things in other places.
Probably we should be able to merge these 2 classes into single one after such steps.
Even if not, it still looks as reasonable cleanup for me.
Differential revision: https://reviews.llvm.org/D30895
llvm-svn: 297714
lld crashes when .eh_frame or .eh_frame_hdr section is discarded
in linker script and there is no PHDRS directive.
Differential revision: https://reviews.llvm.org/D30885
llvm-svn: 297712
Synthetic sections don't belong to any input file, but still they
are input sections. Whenever problem occurs with relocations in
these sections lld crashes in error reporting, trying to print
input file name.
Differential revision: https://reviews.llvm.org/D30889
llvm-svn: 297711
Patch from James Henderson.
If a user has a long link, e.g. due to a large LTO link, they do not
wish to run it and find that it failed because there was a mistake in
their command-line, after they waited for some significant amount of
time. This change adds some basic checking of the linker output file
path, which is run shortly after parsing the command-line and linker
script. An error is emitted if LLD cannot write to the specified path.
Differential Revision: https://reviews.llvm.org/D30449
llvm-svn: 297645
Fix a bug introduced in r297313 which caused them to resolve to the end
of the ELF header in PIEs and DSOs.
Differential Revision: https://reviews.llvm.org/D30843
llvm-svn: 297638
Options can start with `-` or `--` unless they start with "o".
Any option that starts with `-o` should be interpreted as an output
file name. This is a quote from the GNU ld man page.
Note -- there is one exception to this rule. Multiple letter
options that start with a lower case 'o' can only be preceded by
two dashes. This is to reduce confusion with the -o option.
So for example -omagic sets the output file name to magic whereas
--omagic sets the NMAGIC flag on the output.
We didn't handle that properly before.
llvm-svn: 297508
Using .eh_frame input section pattern in linker script currently
causes a crash; this is because .eh_frame input sections require
special handling since they're all combined into a synthetic
section rather than regular output section.
Differential Revision: https://reviews.llvm.org/D30627
llvm-svn: 297501
gold linker manual describes them as:
-z text Do not permit relocations in read-only segments
-z notext Permit relocations in read-only segments (default)
In LLD default is to not permit them. Patch implements -z notext.
Differential revision: https://reviews.llvm.org/D30530
llvm-svn: 297366
.eh_frame_hdr is a header constructed for .eh_frame sections.
We do not proccess .eh_frame when doing relocatable output,
so should not try to create .eh_frame_hdr too.
Previous behavior without this patch is segfault.
Fixes PR32118.
Differential revision: https://reviews.llvm.org/D30566
llvm-svn: 297365
With this we have a single section hierarchy. It is a bit less code,
but the main advantage will be in a future patch being able to handle
foo = symbol_in_obj;
in a linker script. Currently that fails since we try to find the
output section of symbol_in_obj. With this we should be able to just
return an InputSection from the expression.
llvm-svn: 297313
This change moves the calls to finalizeContent() for each synthetic section
before createThunks(). This will allow us to assign addresses prior to
calling createThunks(). As addition of thunks may add to the static
symbol table and may affect the size of the mips got section we introduce a
couple of additional member functions to update these values.
Differential revision: https://reviews.llvm.org/D29983
llvm-svn: 297277
This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.
Differential Revision: https://reviews.llvm.org/D30637
llvm-svn: 297135
This puts us at parity with bfd, which could already gc this case.
I noticed the sections not being gced when linking a modified freebsd
kernel. A section that was not gced and not mentioned in the linker
script would end up breaking the expected layout. Since fixing the gc
is relatively simple and an improvement, that seems better than trying
to hack the orphan placement code.
There are 173 input section in the entire link whose names are valid C
identifiers, so this is probably not too performance critical.
llvm-svn: 297049
In compare with D30458, this makes Bss/BssRelRo to be pure
synthetic sections.
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
SharedSymbols involved in creating copy relocations are
converted to DefinedRegular, what also simplifies things.
Differential revision: https://reviews.llvm.org/D30541
llvm-svn: 297008
We were not gcing any section whose name was a C identifier. Both gold
and bfd only keep those if they are used.
To avoid having to create the __start/__stop symbols early or doing
string lookups in resolvedReloc, this patch just looks for undefined
symbols __start/__stop to decide if a section is needed or not.
llvm-svn: 296723
This patch adds an option named --thinlto-cache-dir, which specifies the
path to a directory in which to cache native object files for ThinLTO
incremental builds.
Differential Revision: https://reviews.llvm.org/D30509
llvm-svn: 296702
That class had three member functions, and all of them are just reader
methods that did not depend on class members, so they can be just non-
member functions.
Probably we should reorganize the functions themselves because their
return types doesn't make much sense to me, but for now I just moved
these functions out of the class.
llvm-svn: 296700
Looks like .gdb.index and its support classes do things that they don't
have to or shouldn't do do. This patch addresses one of these issues.
GdbHashTab class is a hash table class. Just like other in-memory hash
tables, that incrementally updates its internal data and resizes buckets
as new elements are added so that key lookup is always fast.
But that is completely not necessary.
Unlike debuggers, we only produce hash tables for .gdb.index and
never read them. So incrementally updating a hash table in memory is
just a waste of resource and complicates the code. What we should
do is to accumulate symbols and then create the final hash table
at once.
llvm-svn: 296678
In many places we reset Size to 0 before calling assignOffsets()
manually. Sometimes we don't do that.
It looks we can just always do that inside.
Previous code had:
template <class ELFT> void OutputSection::assignOffsets() {
uint64_t Off = Size;
And tests feels fine with Off = 0.
I think Off = Size make no sence.
Differential revision: https://reviews.llvm.org/D30463
llvm-svn: 296609
This implementation is probably slightly inefficient than before,
but that should be negligible because this is not a performance-
critical pass.
llvm-svn: 296570
Previously, LLD merged all read-only sections. So the following
program prints out "true" if -icf=all is specified.
static const int foo = 1;
static const int bar = 1;
int main() { printf("%s\n", &foo == &bar ? "true" : "false"); }
This is somewhat counter-intuitive, and it actually caused nasty issues.
One example is https://bugs.chromium.org/p/chromium/issues/detail?id=682773#c24.
This patch changes the way how it works. Now ICF merges only functions
(i.e. executable sections).
Differential Revision: https://reviews.llvm.org/D30365
llvm-svn: 296534
I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.
Differential Revision: https://reviews.llvm.org/D30441
llvm-svn: 296505
This reverts commit r296378.
I am pretty sure this is incorrect. In particular, for just
.cfi_startproc
nop
.cfi_endproc
We now add an extra 4 zeros that neither bfd nor gold add.
llvm-svn: 296503
There are many special cases and a layer of abstraction or two in the
way, but the VA calculation in the typical case is actually very simple
and probably makes perfect sense even to somebody new to linkers.
Also, this line brings together many components and is a good place to
start understanding the linker (or improve one's existing
understanding).
llvm-svn: 296451
Naively it seemed at first like getVA had the responsibility of adding
the addend, and getSymVA had the responsibility of getting the symbol
VA.
So it was not obvious to me at first why getVA passes Addend to
getSymVA. In fact, it passes it as a mutable reference.
It turns out that it only matters for SHF_MERGE sections, and in
particular only for STT_SECTION symbols that are used as a hack for
reducing the number of local symbols (e.g. to avoid a local symbol for
each string in the string table).
llvm-svn: 296448
In other places in LLD, we use write32<E> instead of Elf_Word.
This patch uses the same technique in the hash table classes.
The hash table classes needs improving as they have almost no
comments. We at least need to describe the hash table structure
and why we have to support two different on-disk hash tables
for the same purpose. I'll do that later.
llvm-svn: 296439
Previously, these two functions put their symbols in different queues.
Now that the queues have been merged. So there's no point to keep two
separate functions.
llvm-svn: 296435
That function doesn't use any member of SymbolTableSection, so I
couldn't see a reason to make it a member of that class. The function
takes a SymbolBody, so it is more natural to make it a member of
SymbolBody.
llvm-svn: 296433
Previously, there were three conditions: .symtab, .dynsym or we are
producing a relocatable output. Turned out that the third condition is
the same as the first one. This patch removes that third condition and
simplify code.
llvm-svn: 296431
We really need to find a way to get this info from a single point of
truth in the LLVM backend, but it seems that the EM_* constants are
buried deep inside the constructors of the MCAsmBackend's.
For now, just fill in entries as we run into cases. AFAIK these mappings
are largely immutable, so we get a 75% discount on the technical debt
(code is duplicated, but little chance of divergence).
llvm-svn: 296429
The previous code was a bit hard to understand because it unnecessarily
distinguished local and non-local symbols. It had NumLocals member
variable, but that variable didn't have a number of local symbols but
had some value that I cannot describe easily.
This patch rewrites SynbolTableSection::finalizeContents and
SymbolTableSection::writeTo to make it easy to understand. NumLocals
member variable has been removed, and writeGlobalSymbols and
writeLocalSymbols have been merged into one function.
There's still a piece of code that I think unnecessary. I'm not removing
that code in this patch, but will do in a follow-up patch.
llvm-svn: 296423
This part of code is hard to understand because NumLocals does not
actually mean the number of local symbols but something else (!).
We need to rewrite. But before that we need to clean it up.
llvm-svn: 296400
Patch by Mark Kettenis.
Currenlty ld.lld does not add a terminator (a CIE with its length field
set to zero) to the .eh_frame sections it generates. While the relevant
standards (the AMD64 SysV ABI and the Linux LSB) are not explicit about
this, such a terminator is expected by some unwinder implementations and
seems to be always emitted by ld.bfd. In addition to that, the Linux LSB
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME
explicitly says that
The .eh_frame section shall contain 1 or more Call Frame Information
(CFI) records.
Currently, if the .eh_frame sections of the input files only contain
terminators, ld.lld emits a zero=sized .eh_frame section
which clearly doesn't meet that requirement.
The diff makes sure a terminator gets added to each .eh_frame section
and adjusts all the relevant tests to account for that. An additional
test isn't needed as these adjustments mean that the existence of the
terminator is tested for by several tests already.
Differential Revision: https://reviews.llvm.org/D30335
llvm-svn: 296378
The list of all input sections was defined in SymbolTable class for a
historical reason. The list itself is not a template. However, because
SymbolTable class is a template, we needed to pass around ELFT to access
the list. This patch moves the list out of the class so that it doesn't
need ELFT.
llvm-svn: 296309
__ehdr_start should be pointing to ELF file headers, not program
headers.
This is a reland of D30319.
Differential Revision: https://reviews.llvm.org/D30323
llvm-svn: 296085
With this we complete the transition out of special output sections,
and with the previous patches it should be possible to merge
OutputSectionBase and OuputSection.
llvm-svn: 296023
With the current design an InputSection is basically anything that
goes directly in a OutputSection. That includes plain input section
but also synthetic sections, so this should probably not be a
template.
llvm-svn: 295993
We have InputSection, MergeInputSection and EhInputSection, so
isa<MergeInputSection> is equivalent to !isa<InputSection> && !isa<
EhInputSection>.
llvm-svn: 295937
We shouldn't report an error for R_*_NONE relocs since we're emitting
them when writing relocations to discarded sections.
Differential Revision: https://reviews.llvm.org/D30279
llvm-svn: 295936
LLD is a multi-threaded program. errs() or outs() are not guaranteed
to be thread-safe (they are actually not).
LLD's message(), log() or error() are thread-safe. We should use them.
llvm-svn: 295787
This change exposes the symbol table insert method and uses it to
insert the linkerscript defined symbols directly into the symbol
table to avoid unnecessarily pulling the object out of an archive.
Differential Revision: https://reviews.llvm.org/D30224
llvm-svn: 295780
Patch fixes PR32024.
Sections that were not marked as Live has null output section.
Previously we tried to access that field and segfaulted.
Differential revision: https://reviews.llvm.org/D30188
llvm-svn: 295727
Previously we evaluated the values of LMA incorrectly for next cases:
.text : AT(ADDR(.text) - 0xffffffff80000000) { ... }
.data : AT(ADDR(.data) - 0xffffffff80000000) { ... }
.init.begin : AT(ADDR(.init.begin) - 0xffffffff80000000) { ... }
Reason was that we evaluated offset when VA was not assigned. For case above
we ended up with 3 loads that has similar LMA and it was incorrect.
That is critical for linux kernel.
Patch updates the offset after VA calculation. That fixes the issue.
Differential revision: https://reviews.llvm.org/D30163
llvm-svn: 295722
Previously LLD would error out just "ld.lld: error: unable to move location counter backward"
What does not really reveal the place of issue,
Patch adds location to the output.
Differential revision: https://reviews.llvm.org/D30187
llvm-svn: 295720
Previously ASSERT we implemented returned expression value.
Ex:
. = ASSERT(0x100);
would set Dot value to 0x100
Form of assert when it is assigned to Dot was implemented for
compatibility with very old GNU ld which required it.
Some scripts in the wild, including linux kernel scripts
use such ASSERTs at the end for doing different checks.
Currently we fail with "unable to move location counter backward"
for such scripts. Patch changes ASSERT to return location counter
value to fix that.
Differential revision: https://reviews.llvm.org/D30171
llvm-svn: 295703
This change moves the SymbolBodies with isLocal() == true before the global
symbols then calculating NumLocals rather than assuming all locals are
added before globals and the first NumLocals have isLocal() == true. This
permits Thunks to be moved after the pass that adds global symbols from
synthetics to the symbol table.
Differential revision: https://reviews.llvm.org/D30085
llvm-svn: 295650
Previously LLD crashed on on provided testcases because "/DISCARD/" was
not supported. Patch implements that.
After this I think there is no known issues with --emit-relocs implementation
required for linux kernel linking.
Differential revision: https://reviews.llvm.org/D29273
llvm-svn: 295488
I splitted it from D29273.
Since we plan to make relocatable sections as dependent for target ones for
--emit-relocs implementation, this change is required to support .eh_frame case.
EhInputSection inherets from InputSectionBase and not from InputSection.
So for case when it has relocation section, it should be able to access DependentSections
vector.
This case is real for Linux kernel.
Differential revision: https://reviews.llvm.org/D30084
llvm-svn: 295483
This is a small difference I noticed to gold and bfd. When given
--print-gc-sections, we print sections a linkerscript marks
DISCARD. The other linkers don't.
llvm-svn: 295467
This case should be possible to handle, but it is hard:
* In order to create program headers correctly, we have to scan the
sections in the order they are in the file.
* To find that order, we have to "execute" the linker script.
* The linker script can contain SIZEOF_HEADERS.
So to support this we have to start with a guess of how many headers
we need (3), run the linker script and try to create the program
headers. If it turns out we need more headers, we run the script again
with a larger SIZEOF_HEADERS.
Also, running the linker script depends on knowing the size of the
sections, so we have to finalize them. But creating the program
headers can change the value stored in some sections, so we have to
split size finalization and content finalization.
Looks like the last part is also needed for range extension thunks, so
we might support this at some point. For now just report an error
instead of producing broken files.
llvm-svn: 295458
Without this we would produce two relocation sections pointing to the
same section, which gnu tools reject.
This fixes pr31986.
The implementation of -r/--emit-reloc is getting fairly
complicated. But lets get the test passing before trying to refactor
it.
llvm-svn: 295385
SHF_LINK_ORDER sections adds special ordering requirements.
Such sections references other sections. Previously we would crash
if section that other were referenced to was discarded by script.
Patch fixes that by discarding all dependent sections in that case.
It supports chained dependencies, testcase is provided.
Differential revision: https://reviews.llvm.org/D30033
llvm-svn: 295332
Unfortunately, the common way of writing linker scripts seems to be
to get the output of ld.bfd --verbose and edit it a bit.
Also unfortunately, the bfd default script contains things like
.rela.dyn : { *(... .rela.data ...) }
but bfd actually ignores that for -emit-relocs, so we have to do the
same.
llvm-svn: 295324
That fixes a case when section has more than one metadata
section. Previously GC would collect one of such sections
because we had implementation that stored only last one as
dependent.
Differential revision: https://reviews.llvm.org/D29981
llvm-svn: 295298
This patch removes NeedsCopyOrPltAddr and instead add two variables,
NeedsCopy and NeedsPltAddr. This uses one more bit in Symbol class,
but the actual size doesn't increase because we had unused bits.
This should improve code readability.
llvm-svn: 295287
This is slightly inefficient than the previous code, but that is really
negligible as this function is usually called at most only a few times.
llvm-svn: 295282
Previously, space in a BSS section for copy relocations are reserved
in a special way. We directly manipulated size of the BSS section.
r294577 changed the way of doing it. Now, we create an instance of
CopyRelSection (which is a synthetic input section) for each copy
relocation.
This patch removes the remains of the old way and add CopyRelSections
to BSS sections using `addSections` function, which is the usual
way to add an input section to an output section.
llvm-svn: 295278
In the target dependent code we already always return a int64_t. In
the target independent code we carefully use uintX_t, which has the
same result given 2 complement rules.
This just simplifies the code to use int64_t everywhere.
llvm-svn: 295263
For CloudABI I'm only interested in generating non-PIC/PIE executables
on armv6 and i686, as PIE introduces larger overhead than on aarch64 and
x86_64. Still, I want to be able to instruct the linker to generate a
dynamic symbol table if requested. One example use for this is that
dynamic symbol tables can be used by programs to print nicely formatted
stacktraces, including symbol names.
Right now there seems to be some logic in LLD that it only wants to emit
dynamic symbol tables when either linking against libraries or when
building PIC. Let's extend this to also take --export-dynamic into
account.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D29982
llvm-svn: 295240
The linker script lexer is context-sensitive. In the regular context,
arithmetic operator characters are regular characters, but in the
expression context, they are independent tokens. This afects how the
lexer tokenizes "3*4", for example. (This kind of expression is real;
the Linux kernel uses it.)
This patch defines function `maybeSplitExpr`. This function splits the
current token into multiple expression tokens if the lexer is in the
expression context.
Differential Revision: https://reviews.llvm.org/D29963
llvm-svn: 295225
If target of R_MIPS_GOT16 relocation is a local symbol its addend
is high 16 bits of complete addend. To calculate a final value, the addend
of this relocation is read, shifted to the left and combined with addend
of paired R_MIPS_LO16 relocation. To save updated addend when the linker
produces a relocatable output, we need to store high 16 bits of the
addend's value. It is different from the case of writing the relocation
result when the linker saves a 16-bit GOT index as-is.
llvm-svn: 295159
This is still not sufficient for lld to handle its own output when a
fde points to a discarded section. I am investigating if it is better
to change the -r output or make lld able to read the current version.
llvm-svn: 295141
This is a really horrible case. If a .eh_frame points to a discarded
section, it is not clear what is the correct thing to do.
It looks like ld.bfd discards the entire .eh_frame content and gold
discards the second relocation, leaving one frame with an fde that
refers to a bogus location. This is similar to what gold does.
llvm-svn: 295133
This reverts commit r295102.
In the link of seabios the assumption seems to be that the section has
an actual address, so this is not sufficient. Changing the assembly
code to add a "a" flag seems like the correct thing to do instead of
extending this hack.
Sorry about the noise.
Original message:
Relax the restriction on what relocations can be in a non-alloc section.
The main thing that they can't have is relocations that require the
creation of gots or plt. For now also accept R_PC.
Found while linking seabios.
llvm-svn: 295130
The main thing that they can't have is relocations that require the
creation of gots or plt. For now also accept R_PC.
Found while linking seabios.
llvm-svn: 295102
If we had SHT_GROUP sections, then when -r was used we might crash.
This is PR31952.
Issue happened because we emited relocation section though its target was discared
because was a member of duplicated group. When we tried to get VA of target,
segfault happened.
Core cause is the bug that GNU as 2.27 (and probably later versions) has.
In compare with llvm-mc, it does not include relocation sections into the group,
like shown in testcase. This patch covers that case.
Differential revision: https://reviews.llvm.org/D29929
llvm-svn: 295067
Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.
The same we did earlier for PC ones,
currenly LLD fails to link linux kernel,
reporting relocation out of range because of this.
Differential revision: https://reviews.llvm.org/D29714
llvm-svn: 295052
Unfortunately some consumers of our .o files produced with -r expect
only one section symbol per section. That is true of at least of go's
own linker.
Combining them is a somewhat convoluted process. We have to create a
symbol for every section since we don't know which ones will be
needed. The relocation sections also have to be written first to
handle the Elf_Rel addend.
I did consider a completely different approach:
We could remove the -r special case of relocation sections when
reading. We would instead have a copyRelocs function that is used
instead of scanRelocs. It would create a DynamicReloc for each
relocation and a RelocationSection for each input relocation section.
A complication of such change is that DynamicReloc would have to take
a section index and a input section instead of a symbol since with
-emit-relocs some DynamicReloc would hold relocations referring to the
dynamic symbol table and other to the static symbol table.
That would be a pretty big change, and if we do it it is probably
better to do it as a refactoring.
llvm-svn: 294816
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
Much of the code in PltSection and IPltSection is similar, we identify
the IPlt by a HeaderSize of 0 and alter our behaviour in the member
functions appropriately:
-Iplt does not have a header
-Iplt always follows after the Plt
Differential Revision: https://reviews.llvm.org/D29664
llvm-svn: 294579
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.
Differential Revision: https://reviews.llvm.org/D29637
llvm-svn: 294577
with temporarily file name fix in testcase.
Original commit message:
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294469
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294464
OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)
We did not support that, because got 3 lexer tokens here after recent changes.
This trivial patch fixes the issue, now whole expression inside
OUTPUT_ARCH is just ignored.
Differential revision: https://reviews.llvm.org/D29640
llvm-svn: 294432
LLD already parses ALIGN expression to specifiy alignment for output
sections in linker scripts but it never applies the alignment to the
output section. This change handles that.
Differential Revision: https://reviews.llvm.org/D29689
llvm-svn: 294374
DefinedSynthetic symbols are attached to sections,
for the case when such symbol was attached to non-allocated section,
we calculated its value incorrectly.
We subtracted Body->Section->Addr, but non-allocatable sections
should have zero VA in output and therefore result value was wrong.
And at the same time we have Body->Section->Addr != 0 for them
internally because use it for calculation of section size.
Patch fixes calculation of such symbols values.
Differential revision: https://reviews.llvm.org/D29653
llvm-svn: 294322
We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.
Differential revision: https://reviews.llvm.org/D29582
llvm-svn: 294290
Previously we did not do that. For example, for R_386_PC8,
0xFF addend was not treated as 0xFFFFFFFF(-1),
but was 0x000000FF.
Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation
overflow as a result.
Differential revision: https://reviews.llvm.org/D29490
llvm-svn: 294289
If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.
llvm-svn: 294253
We now create a dummy section with index 1 before processing the
linker script.
Thanks to George Rimar for finding the bug and providing the initial
testcase.
llvm-svn: 294252
George Rimar