The current support for V1 ABI in LLD is incomplete.
This patch removes V1 ABI support and changes the default behavior to V2 ABI,
issuing an error when using the V1 ABI. It also updates the testcases to V2
and removes any V1 specific tests.
Differential Revision: https://reviews.llvm.org/D46316
llvm-svn: 331529
Currently LLD sets OutSecOff in addSection for input sections.
That is a fake offset (just a rude approximation to remember the order),
used for sorting SHF_LINK_ORDER sections
(see resolveShfLinkOrder, compareByFilePosition).
There are 2 problems with such approach:
1. We currently change and reuse Size field as a value assigned. Changing size is
not good because leads to bugs. Currently, SIZEOF(.bss) for empty .bss returns 2
because we add two empty synthetic sections and increase size twice by 1.
(See PR37011: https://bugs.llvm.org/show_bug.cgi?id=37011)
2. Such approach simply does not work when --symbol-ordering-file is involved,
because processing of the ordering file might break the initial section order.
This fixes PR37011.
Differential revision: https://reviews.llvm.org/D45368
llvm-svn: 329560
Our code assumes all input sections in an output SHF_LINK_ORDER
section has SHF_LINK_ORDER flag. We do not check that and that can cause a crash.
That happens because we call
std::stable_sort(Sections.begin(), Sections.end(), compareByFilePosition);,
where compareByFilePosition predicate does not expect to see
null when calls getLinkOrderDep.
The same might happen when sections refer to non-regular sections.
Test cases demonstrate the issues, patch fixes them.
Differential revision: https://reviews.llvm.org/D44193
llvm-svn: 327006
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
This fixes pr36475.
I think this code can be simplified a bit, but I would like to check
in the more direct fix if we are in agreement on the direction and
then refactor.
This is not something that bfd does. The issue is not noticed in bfd
because it keeps fewer sections from the linkerscript in the output.
The reasons why it seems reasonable to do this:
- As George noticed, we would still keep the flags if the output
section had both an empty synthetic section and a regular section
- We need an heuristic to find the flags of output sections. Using the
flags of a synthetic section that would have been there seems a
reasonable heuristic.
llvm-svn: 326137
We sometimes need to iterate over input sections for a given
output section. It is not very convinent because we have to iterate
over section descriptions.
Patch introduces getInputSections helper, it simplifies things.
Differential revision: https://reviews.llvm.org/D43574
llvm-svn: 325763
Previously, in r320472, I moved the calculation of section offsets and sizes
for compressed debug sections into maybeCompress, which happens before
assignAddresses, so that the compression had the required information. However,
I failed to take account of relocations that patch such sections. This had two
effects:
1. A race condition existed when a debug section referred to a different debug
section (see PR35788).
2. References to symbols in non-debug sections would be patched incorrectly.
This is because the addresses of such symbols are not calculated until after
assignAddresses (this was a partial regression caused by r320472, but they
could still have been broken before, in the event that a custom layout was used
in a linker script).
assignAddresses does not need to know about the output section size of
non-allocatable sections, because they do not affect the value of Dot. This
means that there is no longer a reason not to support custom layout of
compressed debug sections, as far as I'm aware. These two points allow for
delaying when maybeCompress can be called, removing the need for the loop I
previously added to calculate the section size, and therefore the race
condition. Furthermore, by delaying, we fix the issues of relocations getting
incorrect symbol values, because they have now all been finalized.
llvm-svn: 321986
Moving the SHF_LINK_ORDER processing out of OutputSection::finalize()
means that we no longer need to copy all InputSections as we now only need
the first one.
Differential Revision: https://reviews.llvm.org/D40966
llvm-svn: 320478
By moving this step before thunk creation and other processing that depends
on the size of sections, we permit removal of duplicates in the .ARM.exidx
section.
Differential Revision: https://reviews.llvm.org/D40964
llvm-svn: 320477
The size of an OutputSection is calculated early, to aid handling of compressed
debug sections. However, subsequent to this point, unused synthetic sections are
removed. In the event that an OutputSection, from which such an InputSection is
removed, is still required (e.g. because it has a symbol assignment), and no longer
has any InputSections, dot assignments, or BYTE()-family directives, the size
member is never updated when processing the commands. If the removed InputSection
had a non-zero size (such as a .got.plt section), the section ends up with the
wrong size in the output.
The fix is to reset the OutputSection size prior to processing the linker script
commands relating to that OutputSection. This ensures that the size is correct even
in the above situation.
Additionally, to reduce the risk of developers misusing OutputSection Size and
InputSection OutSecOff, they are set to simply the number of InputSections in an
OutputSection, and the corresponding index respectively. We cannot completely
stop using them, due to SHF_LINK_ORDER sections requiring them.
Compressed debug sections also require the full size. This is now calculated in
maybeCompress for these kinds of sections.
Reviewers: ruiu, rafael
Differential Revision: https://reviews.llvm.org/D38361
llvm-svn: 320472
When an output section has no byte commands and has no input sections then it
would be ideal if the type of the section is SHT_NOBITS so that the file can
take up less space. This change sets the default type of of output sections to
SHT_NOBITS instead of SHT_PROGBITS to allow this. This required some minor test
changes (which double as tests for this new behavior) but extend-pt-load.s had
be changed in a non-trivial way. Since it seems to me that the point of the
test is to point out the consequences of how flags are assigned to output
sections that don't have input sections I changed the test to work and still
show how the memsize of the executable segment was changed.
Differential Revision: https://reviews.llvm.org/D41082
llvm-svn: 320437
An output section can include elements from two input sections with
different sh_entsize. When that happens the output section itself
should not have a sh_entsize.
llvm-svn: 318311
That class is used only by LinkerScript.cpp, so we should move it to
that file. Also, it no longer has to be a "factory" class. It can just
be a non-member function.
llvm-svn: 317427
Stop using SectionKey for creating output sections.
Initially SectionKey was designed because we merged section with
use of Flags and Alignment fields. Currently LLD merges them by name only,
except the case when -relocatable output is produced. In that case
we still merge sections only with the same flags and alignment.
There is probably no issue at all to stop using Flags and Alignment for -r and
just disable the merging in that case.
After doing that change we can get rid of using SectionKey. That is not only
simplifies the code, but also gives some perfomance boost.
I tried to link chrome and mozilla, results are next:
* chrome link time goes from 1,666750355s to 1,551585364s, that is about 7%.
* mozilla time changes from 3,210261947 to 3,153782940, or about 2%.
Differential revision: https://reviews.llvm.org/D39594
llvm-svn: 317406
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by
perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)
nd clang-format-diff.
Differential Revision: https://reviews.llvm.org/D39459
llvm-svn: 317370
It does not seem that createSections() is a good place for
applying sorting. Patch changes code to do that inside
sortSections(), which looks more appropriate place.
Differential revision: https://reviews.llvm.org/D39371
llvm-svn: 316893
This moves reporting of garbage collected sections right after
we do GC. That simplifies things.
Differential revision: https://reviews.llvm.org/D39058
llvm-svn: 316759
Summary:
This will allow using the functionality from other linkers. It is also
a prerequisite for sharing the error logging code.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38822
llvm-svn: 315725
"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.
llvm-svn: 315409
Previously, when we added an input section to an output section, we
called `OutputSectionFactory::addInputSec`. This isn't a good design
because, a factory class is intended to create a new object and
return it, but in this use case, it will never create a new object.
This patch fixes the design flaw.
llvm-svn: 315138
Factory::addInputSec added an output section to Script->Opt.Commands,
but that is too subtle. This patch makes it explicit so that it is easy
to see when a new element is added to Script->Opt.Commands.
llvm-svn: 315129
addSection function was hard to read because it behaves differently
depending on its arguments but what exactly it does is not clear.
Now it should be better. Still, it is not clear (not what but) why
it does what it does, but I'll take a look at it later.
llvm-svn: 315124
This is PR34506.
Imagine we have 2 sections the same name but different COMDAT groups:
.section .foo,"axG",@progbits,bar,comdat
.section .foo,"axG",@progbits,zed,comdat
When linking relocatable we do not merge SHT_GROUP sections. But still would merge
both input sections .foo into single output section .foo.
As a result we will have 2 different SHT_GROUPs containing the same section, what
is wrong.
Patch fixes the issue, preventing merging SHF_GROUP sections with any others.
Differential revision: https://reviews.llvm.org/D37574
llvm-svn: 313621
Patch removes one of OutputSectionFactory::addInputSec methods.
That allows to simplify reporting of discarded sections and
should help to D37561.
Differential revision: https://reviews.llvm.org/D37735
llvm-svn: 313361
This is PR33889,
Patch adds support of combination of linkerscript and
-symbol-ordering-file option.
If no sorting commands are present in script inside section declaration
and no --sort-section option specified, code uses sorting from ordering
file if any exist.
Differential revision: https://reviews.llvm.org/D35843
llvm-svn: 310045
This is a bit of a hack, but it is *so* convenient.
Now that we create synthetic linker scripts when none is provided, we
always have to handle paired OutputSection and OutputsectionCommand and
keep a mapping from one to the other.
This patch simplifies things by merging them and creating what used to
be OutputSectionCommands really early.
llvm-svn: 309311
Zaara Syeda