This fixes pr32031 by representing the expressions results as a
SectionBase and offset. This allows us to use an input section
directly instead of getting lost trying to compute an offset in an
outputsection when not all the information is available yet.
This also creates a struct to represent the *value* of and expression,
allowing the expression itself to be a simple typedef. I think this is
easier to read and will make it easier to extend the expression
computation to handle more complicated cases.
llvm-svn: 298079
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
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
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
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
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
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
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
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
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
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
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
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
This is a fix for Bugzilla 31813.
The problem is that the tokenizer does not create a separate token for
":" unless there's white space before it. Changed it to always create
a token for ":" and reworked some logic that relied on ":" being
attached to some tokens like "global:" and "local:".
llvm-svn: 294006
This is alternative to D28857 which was incorrect.
One of linux scripts contains:
vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.
And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol
This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).
Differential revision: https://reviews.llvm.org/D29332
llvm-svn: 293748
Linux kernel linkerscript contains additional semicolon (last line):
.apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
__apicdrivers = .;
*(.apicdrivers);
I checked that both gold and bfd are able to parse something like:
.text : { ;;*(.text);;S = 0;; } }
Patch do the same.
Differential revision: https://reviews.llvm.org/D29276
llvm-svn: 293612
[ELF] Fixed formatting. NFC
and
[ELF] Bypass section type check
Differential revision: https://reviews.llvm.org/D28761
They do the opposite of what was asked for in the code review.
llvm-svn: 293320
As specified here:
* https://sourceware.org/binutils/docs/ld/MEMORY.html#MEMORY
There are two deviations from what is specified for GNU ld:
1. Only integer constants and *not* constant expressions
are allowed in `LENGTH` and `ORIGIN` initializations.
2. The `I` and `L` attributes are *not* implemented.
With (1) there is currently no easy way to evaluate integer
only constant expressions. This can be enhanced in the
future.
With (2) it isn't clear how these flags map to the `SHF_*`
flags or if they even make sense for an ELF linker.
Differential Revision: https://reviews.llvm.org/D28911
llvm-svn: 292875
Found that during attempts of linking linux kernel,
previously we partially duplicated code from getOutputSection(),
and it missed commons symbol case.
Differential revision: https://reviews.llvm.org/D28903
llvm-svn: 292594
This actually simplifies the code a bit as now all local symbols are
handled uniformly.
This should fix the build of www/webkit2-gtk3.
llvm-svn: 291569
This patch allows for linker scripts to assign a new value
to a symbol that is already defined (either in an object file
or the linker script itself).
llvm-svn: 291459
Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.
llvm-svn: 291413
After Mark's patch I was wondering what was the rationale for the ELF
spec requiring us to merge only sections with matching flags and
types. I tried emailing
https://groups.google.com/forum/#!forum/generic-abi, but looks like my
emails are not being posted (the list is probably moderated). I
emailed Cary Coutant instead.
Cary pointed out that the section was a late addition and didn't got
the scrutiny it deserved. Given that and the problems found by
implementing the letter of the standard, I propose changing lld to
merge all sections with the same name and issue errors if the types or
some critical flags are different.
This should allow an unmodified firefox linked with lld to run.
This also merges some code with the linkerscript path.
llvm-svn: 291107
DefinedSynthetic is not created for a real ELF object, so it doesn't
have to be a template function. It has a virtual st_value, which is
either 32 bit or 64 bit, but we can simply use 64 bit.
llvm-svn: 290241
It was revealed by D27831.
If we have linkerscript that includes another one that sets OUTPUT for example:
RUN: echo "INCLUDE \"foo.script\"" > %t.script
RUN: echo "OUTPUT(\"%t.out\")" > %T/foo.script
then we do:
void ScriptParser::readInclude() {
...
std::unique_ptr<MemoryBuffer> &MB = *MBOrErr;
tokenize(MB->getMemBufferRef());
OwningMBs.push_back(std::move(MB));
}
void ScriptParser::readOutput() {
...
Config->OutputFile = unquote(Tok);
...
}
Problem is that OwningMBs are destroyed after script parser do its job.
So all Toks are dead and Config->OutputFile points to destroyed data.
Patch suggests to save all included scripts into using string Saver.
Differential revision: https://reviews.llvm.org/D27987
llvm-svn: 290238
This handles all the corner cases if setting a section address:
- If the address is too low, we cannot allocate the program headers.
- If the load address is lowered, we have to do that before finalize
This also shares some code with the linker script since it was already
hitting similar cases.
This is used by the freebsd boot loader. It is not clear if we need to
support this with a non binary output, but it is not as bad as I was
expecting.
llvm-svn: 290136
Rafael Espindola