Thunks are now generated per InputSectionDescription instead of per
OutputSection. This allows created ThunkSections to be inserted directly
into InputSectionDescription.
Changes in this patch:
- Loop over InputSectionDescriptions to find relocations to Thunks
- Generate a ThunkSection per InputSectionDescription
- Remove synchronize() as we no longer need it
- Move fabricateDefaultCommands() before createThunks
Differential Revision: https://reviews.llvm.org/D33835
llvm-svn: 304887
When linking linux kernel LLD currently reports next errors:
ld: error: unable to evaluate expression: input section .head.text has no output section assigned
ld: error: At least one side of the expression must be absolute
ld: error: At least one side of the expression must be absolute
That does not provide file/line information and overall looks unclear.
Patch adds location information to ExprValue and that allows
to provide more clear error messages.
Differential revision: https://reviews.llvm.org/D33943
llvm-svn: 304881
We were looking up sections by name during expression evaluation. By
keeping track of forward declarations we can do the lookup during
script parsing.
Doing the lookup earlier will be more efficient when assignAddresses
is run twice and removes two uses of OutputSections.
llvm-svn: 304381
While the following expression is handled fine:
PROVIDE_HIDDEN(newsym = oldsym + address);
The following expression triggers an error because the expression
is evaluated as absolute:
PROVIDE_HIDDEN(newsym = ALIGN(oldsym, CONSTANT(MAXPAGESIZE)) + address);
To avoid this error, we use late evaluation for ALIGN by making the
alignment an attribute of the expression itself.
Differential Revision: https://reviews.llvm.org/D33629
llvm-svn: 304185
This reduces how many times we have to map from OutputSection to
OutputSectionCommand. It is a required step to moving
clearOutputSections earlier.
In order to always use writeTo in OutputSectionCommand we have to call
fabricateDefaultCommands for -r links and move section compression
after it.
llvm-svn: 303784
By the time we get to linker scripts, all special InputSectionBase
should have been combined into synthetic sections, which are a type of
InputSection. The net result is that we can use InputSection in a few
places that were using InputSectionBase.
llvm-svn: 303702
We can set SectionIndex tentatively as we process the linker script
instead of looking it repeatedly.
In general we should try to have as few name lookups as possible.
llvm-svn: 302299
In the non linker script case we would try very early to find out if
we could allocate the headers. Failing to do that would add extra
alignment to the first ro section, since we would set PageAlign
thinking it was the first section in the PT_LOAD.
In the linker script case the header allocation must be done in the
end, causing some duplication.
We now tentatively add the headers to the first PT_LOAD and if it
turns out they don't fit, remove them. With this we only need to
allocate the headers in one place in the code.
llvm-svn: 302186
We were correctly computing the size contribution of a .tbss input
section (it is none), but we were incorrectly considering the
alignment of the output section: it was advancing Dot instead of
ThreadBssOffset.
As far as I can tell this was always wrong in our linkerscript
implementation, but that became more visible now that the code is
shared with the non linker script case.
llvm-svn: 302107
This version uses a set to speed up the synchronize method.
Original message:
Remove LinkerScript::flush.
This patch replaces flush with a last ditch attempt at synchronizing
the section list with the linker script "AST".
The synchronization is a bit of a hack and should in time be avoided
by creating the AST earlier so that modifications can be made directly
to it instead of modifying the section list and synchronizing it back.
This is the main step for fixing
https://bugs.llvm.org/show_bug.cgi?id=32816. With this in place I
think the only missing thing would be to have processCommands assign
section indexes as dummy offsets so that the sort in
OutputSection::finalize works.
With this LinkerScript::assignAddresses becomes much simpler, which
should help with the thunk work.
llvm-svn: 301745
This reverts commit r301678 since that change significantly slowed
down the linker. Before this patch, LLD could link clang in 8 seconds,
but with this patch it took 40 seconds.
llvm-svn: 301709
This patch replaces flush with a last ditch attempt at synchronizing
the section list with the linker script "AST".
The synchronization is a bit of a hack and should in time be avoided
by creating the AST earlier so that modifications can be made directly
to it instead of modifying the section list and synchronizing it back.
This is the main step for fixing
https://bugs.llvm.org/show_bug.cgi?id=32816. With this in place I
think the only missing thing would be to have processCommands assign
section indexes as dummy offsets so that the sort in
OutputSection::finalize works.
With this LinkerScript::assignAddresses becomes much simpler, which
should help with the thunk work.
llvm-svn: 301678
This change fabricates linker script commands for the case where there is
no linker script SECTIONS to control address assignment. This permits us
to have a single Script->assignAddresses() function.
There is a small change in user-visible-behavior with respect to the
handling of .tbss SHT_NOBITS, SHF_TLS as the Script->assignAddresses()
requires setDot() to be called with monotically increasing addresses.
The tls-offset.s test has been updated so that the script and non-script
results match.
This change should make the non-script behavior of lld closer to an
equivalent linker script.
Differential Revision: https://reviews.llvm.org/D31888
llvm-svn: 300687
Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.
Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D30886
Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635
Symbols referenced by linker scripts are not necessarily be undefined,
so the previous name didn't convey the meaining of the variable.
llvm-svn: 299573
LinkerScript.cpp contains both the linker script processor and the
linker script parser. I put both into a single file, but the file grown
too large, so it's time to put them into two different files.
llvm-svn: 299515
This requires collectign all symbols referenced in the linker script
and adding them to symbol table as undefined symbol.
Differential Revision: https://reviews.llvm.org/D31147
llvm-svn: 298577
LinkerScript used to be a template class, so we couldn't instantiate
that class in elf::link. We instantiated ScriptConfig class earlier
instead so that the linker script parser can store configurations to
the object.
Now that LinkerScript is not a template, it doesn't make sense to
separate ScriptConfig from LinkerScript. This patch merges them.
llvm-svn: 298457
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
Rafael Espindola