This add support for HIDDEN command which can be used to define
a symbol that will be hidden and won't be exported.
Differential Revision: https://reviews.llvm.org/D23534
llvm-svn: 278770
Previously we searched output section by name to assign VA. That did not
work in the case when multiple output sections with different constraints were defined in script.
Testcase shows the possible issue scenario, patch fixes the issue.
Differential revision: https://reviews.llvm.org/D23451
llvm-svn: 278561
After latest changes we combine input sections with
different attributes into single output section.
Problem here is that regular output sections does not
support adding mergeable input sections (and vise versa).
Patch just temporarily disables merging for now at
the same way we do for -O0 for example.
This change helps for linking FreeBSD kernel.
Differential revision: https://reviews.llvm.org/D23447
llvm-svn: 278555
Previously filtering that was used worked incorrectly.
For example for next script it would just remove both sections completely:
SECTIONS {
. = 0x1000;
.aaa : ONLY_IF_RW { *(.aaa.*) }
. = 0x2000;
.aaa : ONLY_IF_RO { *(.aaa.*) }
}
Patch fixes above issues and adds testcase showing the issue. Testcase is a subset of
FreeBSD script which has:
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
...
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
Differential revision: https://reviews.llvm.org/D23326
llvm-svn: 278486
Previously, we created two or more output sections if there are
input sections with the same name but with different attributes.
That is a wrong behavior. This patch fixes the issue.
One thing we need to do is to merge output section attributes.
Currently, we create an output section based on the first input
section's attributes. This may make a wrong output section
attributes. What we need to do is to bitwise-OR attributes.
We'll do it in a follow-up patch.
llvm-svn: 278461
SIZEOF_HEADERS - Return the size in bytes of the output file’s headers.
It is is a feature used in FreeBsd script, for example.
There is a discussion on PR28688 page about it.
Differential revision: https://reviews.llvm.org/D23165
llvm-svn: 278204
I faced that when tried to link FreeBSD kernel.
It was "duplicate symbol: _edata in (internal) and (internal)" error.
_data was a shared symbol that came from hack.so. At first it was replaced with DefinedRegular by the code
disabled in this patch and later when script tried to define the same symbol - the error was shown.
In the same situation (as given in testcase) ld defines them as UND. gold defines as ABS with zero value.
Patch just disables any operations of creating these symbols if script do layout.
Differential revision: https://reviews.llvm.org/D23206
llvm-svn: 277986
ASSERT(exp, message)
Ensure that exp is non-zero. If it is zero, then exit the linker with an error
code, and print message.
ASSERT is useful and was seen in few projects in the wild.
Differential revision: https://reviews.llvm.org/D22912
llvm-svn: 277710
According to spec:
"SORT_BY_ALIGNMENT will sort sections into descending order by
alignment before placing them in the output file"
Previously they were sorted into ascending order.
llvm-svn: 277706
With the previous change, it is now obvious that readProvide in
this context appended new commands to a wrong command list.
It was mistakenly adding new commands to the top level.
Thus, all commands inside output section descriptions were
interpreted as they were written on top level.
PROVIDE command naturally requires symbol assignment support
in the output section description. We don't have that one yet.
I removed the implementation because there's no way to fix it now.
We can resurrect the test once we support the symbol assignment
(with a modification to detect errors that we failed to find as
described.)
llvm-svn: 277687
Previously, a decimal filler expression is interpreted as a byte value.
Gold on the other hand use it as a 32-bit big-endian value.
This patch fixes the compatibility issue.
Differential Revision: https://reviews.llvm.org/D23142
llvm-svn: 277680
Previously we supported only sorting by name.
When there are nested section sorting commands in linker script, there can be at most 1
level of nesting for section sorting commands.
SORT_BY_NAME (SORT_BY_ALIGNMENT (wildcard section pattern)). It will sort the input
sections by name first, then by alignment if 2 sections have the same name.
SORT_BY_ALIGNMENT (SORT_BY_NAME (wildcard section pattern)). It will sort the input
sections by alignment first, then by name if 2 sections have the same alignment.
SORT_BY_NAME (SORT_BY_NAME (wildcard section pattern)) is treated the same as SORT_
BY_NAME (wildcard section pattern).
SORT_BY_ALIGNMENT (SORT_BY_ALIGNMENT (wildcard section pattern)) is treated the
same as SORT_BY_ALIGNMENT (wildcard section pattern).
All other nested section sorting commands are invalid.
Patch implements that all above.
Differential revision: https://reviews.llvm.org/D23019
llvm-svn: 277583
This is a bit of an odd feature. It is normally used in
. = SEGMENT_START(seg, val);
In bfd it evaluates to val or to the value of the corresponding
-T<seg>-segment. Note that the -T<seg>-segment in bfd doesn't actually
change the segment address, just the value this evaluates too,
including in the default linker script.
In gold the -T<seg>-segment options do change the segment address and
seeing this expressions in linker scripts disables the options.
For new this just always evaluates the expression to val.
llvm-svn: 277014
Some scripts can contain SORT(CONSTRUCTORS) expression:
https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?revision=284870&view=markup#l152
for ELF it just a nop:
"When linking object file formats which do not support arbitrary sections, such as ECOFF and XCOFF, the linker will automatically recognize C++ global constructors and destructors by name. For these object file formats, the CONSTRUCTORS command tells the linker to place constructor information in the output section where the CONSTRUCTORS command appears. The CONSTRUCTORS command is ignored for other object file formats."
(http://www.sourceware.org/binutils/docs-2.10/ld_3.html)
So patch implements ignoring.
Differential revision: https://reviews.llvm.org/D22848
llvm-svn: 276965
In compare with what GNU linkers do (https://sourceware.org/binutils/docs/ld/Builtin-Functions.html),
this implementation simple:
Do not touch DATA_SEGMENT_ALIGN, it do what it do now - just aligns to the page boundary.
Parameters of DATA_SEGMENT_RELRO_END is ignored. That should be correct as it is usually just a 24 bytes
shift that allows to protect first 3 entries of got.plt with relro.
(https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?revision=284870&view=markup#l146).
DATA_SEGMENT_RELRO_END just aligns to the page boundary.
That is what expected because all sections that are not affected by relro should be on another memory page.
So at fact the difference with documented behavior is that we do not pad DATA_SEGMENT_ALIGN.
3 entries of got.plt are uncovered by relro, but functionality is simple and equal to lld behavior
for case when script is not given.
Differential revision: https://reviews.llvm.org/D22813
llvm-svn: 276778
We can simplify the evaluation of DATA_SEGMENT_ALIGN
just to simple align(). That way it will work exactly like we have in non-script case.
Change was suggested by Rafael Ávila de Espíndola
Differential revision: https://reviews.llvm.org/D22807
llvm-svn: 276745
PROVIDE request us to define a symbol only if it is referenced and is
not defined by any object included in the link. We created the
symbol in the symbol table no matter what.
Differential Revision: https://reviews.llvm.org/D22739
llvm-svn: 276592