We do not expand memory region correctly for following scripts:
.foo.1 :
{
*(.foo.1)
. += 0x1000;
} > ram
Patch generalizes expanding of output sections and memory
regions in one place and fixes the issue.
Differential revision: https://reviews.llvm.org/D43999
llvm-svn: 326688
LLD can not catch a memory area overflow when using a data command.
If we have the script below:
.foo :
{
*(.foo)
BYTE(0x1)
} > ram
where BYTE overflows the ram region, we do not report it currently.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D43948
llvm-svn: 326545
With the current code if the script has a PHDRS we always obey and try
to allocate a header. This can cause Min - HeaderSize to underflow.
It looks like bfd actually prints an error for this case. With this
patch we do the same.
Found while looking at pr36515.
llvm-svn: 326441
This is PR36515.
Currenly if we have a script like .debug_info 0 : { *(.debug_info) },
we would not remove this section and keep it in the output.
That does not work, because it is common case for
debug sections to have a zero address expression.
Patch changes behavior so that we remove only sections
that do not use symbols in its expressions.
Differential revision: https://reviews.llvm.org/D43863
llvm-svn: 326430
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
We should process symbols inside output section declarations the same way as top-level ones.
Differential Revision: https://reviews.llvm.org/D43008
llvm-svn: 326305
It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.
Differential Revision: https://reviews.llvm.org/D43011
llvm-svn: 326176
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
This continues direction started in D43069.
We can keep sections that are explicitly assigned to segment in script.
It helps to simplify code.
Differential revision: https://reviews.llvm.org/D43571
llvm-svn: 325887
This is for fixing PR36297.
Issue itself is that if we have SECTIONS { .bar (a+b) : { *(.stub) } };
script and no section .stub, when LLD will remove .bar, but
produce output with undefined symbols a and b.
Differential revision: https://reviews.llvm.org/D43069
llvm-svn: 325875
Previously --defsym=foo2=etext+2 would produce incorrect value
for foo2 because expressions did not work correctly with
reserved symbols, section offset was calculated wrong for them.
Fixes PR35744.
Differential revision: https://reviews.llvm.org/D42911
llvm-svn: 324461
Currently symbols assigned or created by linkerscript are not processed early
enough. As a result it is not possible to version them or assign any other flags/properties.
Patch creates Defined symbols for -defsym and linkerscript symbols early,
so that issue from above can be addressed.
It is based on Rafael Espindola's version of D38239 patch.
Fixes PR34121.
Differential revision: https://reviews.llvm.org/D41987
llvm-svn: 323729
If two sections are in the same PT_LOAD, their relatives offsets,
virtual address and physical addresses are all the same.
I initially wanted to have a single global LMAOffset, on the
assumption that every ELF file was in practiced loaded contiguously in
both physical and virtual memory.
Unfortunately that is not the case. The linux kernel has:
LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000
LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000
LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000
LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000
The delta for all but the third PT_LOAD is the same:
0xffffffff80000000. I think the 3rd one is a hack for implementing per
cpu data, but we can't break that.
llvm-svn: 323456
This fixes the crash reported at PR36083.
The issue is that we were trying to put all the sections in the same
PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all
3 PT_LOADs would have the same physical address.
llvm-svn: 323449
When a section placement (AT) command references the section itself,
the physical address of the section in the ELF header was calculated
incorrectly due to alignment happening right after the location
pointer's value was captured.
The problem was diagnosed and the first version of the patch written
by Erick Reyes.
llvm-svn: 322421
AT> lma_region expression allows to specify the memory region
for section load address.
Should fix PR35684.
Differential revision: https://reviews.llvm.org/D41397
llvm-svn: 322359
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
Advance the memory region offset when handling a linker script data
command such as BYTE or LONG. Failure to advance the offset results
in corrupted output with overlapping sections.
Update tests to check for this combination of both a) memory regions
and b) data commands.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35565
Patch by Owen Shaw!
llvm-svn: 321418
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
This is for "Bug 35474 - --emit-relocs produces wrongly-named reloc sections".
LLD currently for scripts like:
.text.boot : { *(.text.boot) }
emits relocation section with name .rela.text because does not take
redefined name of output section into account and builds section name
using rules for non-scripted case. Patch fixes this oddness.
Differential revision: https://reviews.llvm.org/D40652
llvm-svn: 319526
When a linker script has "foo = bar" and bar is the result of a copy
relocation foo should point to the same location in .bss.
This is part of a growing evidence that copy relocations should be
implemented by using replaceSymbol to replace the SharedSymbol with a
Defined.
llvm-svn: 319449
This fixes PR35223.
Here I enabled SHF_MERGE section content merging for -r like
we do for regular linking.
Differential revision: https://reviews.llvm.org/D40026
llvm-svn: 318516
Now that DefinedRegular is the only remaining derived class of
Defined, we can merge the two classes.
Differential Revision: https://reviews.llvm.org/D39667
llvm-svn: 317448
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
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
The way we handle ONLY_IF_RO/ONLY_IF_RW constraints in
processSectionCommands is a bit tricky. If input sections
does no satisfy given constraint we remove command from
commands list. It seems too complex, what we can do instead
is to make the OutputCommand empty. So that at later steps
LLD will remove it just like it deal with other empty output commands.
That allows to simplify the loop a bit.
Differential revision: https://reviews.llvm.org/D39094
llvm-svn: 317082
SymbolBody and Symbol were separated classes due to a historical reason.
Symbol used to be a pointer to a SymbolBody, and the relationship
between Symbol and SymbolBody was n:1.
r2681780 changed that. Since that patch, SymbolBody and Symbol are
allocated next to each other to improve memory locality, and they have
1:1 relationship now. So, the separation of Symbol and SymbolBody no
longer makes sense.
This patch merges them into one class. In order to avoid updating too
many places, I chose SymbolBody as a unified name. I'll rename it Symbol
in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D39406
llvm-svn: 317006
When there is no SECTION commands given, all sections are
technically orphans, but now we handle script orphans sections
and regular "orphans" sections for non-scripted case differently,
though we can handle them at one place.
Patch do that change.
Differential revision: https://reviews.llvm.org/D39045
llvm-svn: 316984
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
"/DISCARD/" is a special section name in the linker script to discard
input sections. Previously, we handled it as if it were a real section,
so an input section can be assigned but dead. However, allowing sections
to be
- assigned and alive (will be emitted),
- not assigned and dead (removed), or
- assigned but dead (???)
feels logically wrong and practically error-prone. This patch removes
the last combination of the states.
llvm-svn: 316622
It is PR34946.
Spec (http://man7.org/linux/man-pages/man1/ld.1.html) tells about
--orphan-handling=MODE, option where MODE can be one of four:
"place", "discard", "warn", "error".
Currently we already report orphans when -verbose given,
what becomes excessive with option implemented.
Patch stops reporting orphans when -versbose is given,
and support "place", "warn" and "error" modes.
It is not yet clear that "discard" mode is useful so it is not supported.
Differential revision: https://reviews.llvm.org/D39000
llvm-svn: 316583
If a struct has a std::unique_ptr member, the logical interpretation
is that that member will be destroyed with the struct.
That is not the case for Ctx. It is has to be deleted earlier and its
lifetime is defined by the functions where the AddressState is
created.
llvm-svn: 316378
George Rimar