Found this operators used in the wild scripts, for example:
__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >>2;
__fixup_entries = (. - _FIXUP_TABLE_)>>2;
Differential revision: https://reviews.llvm.org/D24860
llvm-svn: 282243
The ELF spec doesn't allow relocations to point directly to
a deduplicated COMDAT section but this unfortunately happens in
practice. Bail out early instead of crashing.
Differential Revision: https://reviews.llvm.org/D24750
llvm-svn: 282197
With the recent changes there should always be a 1:1 correspondence in
the correct order between OutputSections and OutputSectionCommands.
llvm-svn: 282176
The actual logic is to keep the output section if the output section
would have been ro/rw.
This is both simpler and more practical, as the intention is linker
scripts is to always keep of of a pair of ONLY_IF_RO/ONLY_IF_RW.
llvm-svn: 282099
This is PR30442.
Previously we were failed to parce complex expressions like:
foo : { *(SORT_BY_NAME(bar) zed) }
Main idea of patch that globs and excludes can be wrapped in a SORT.
There is a difference in semanics of ld/gold:
ld likes:
*(SORT(EXCLUDE_FILE (*file1.o) .foo.1))
gold likes:
*(EXCLUDE_FILE (*file1.o) SORT(.foo.1))
Patch implements ld grammar, complex expressions like
next is not a problem anymore:
.abc : { *(SORT(.foo.* EXCLUDE_FILE (*file1.o) .bar.*) .bar.*) }
Differential revision: https://reviews.llvm.org/D24758
llvm-svn: 282078
When final image has several .bss sections, lld fails
because second .bss always has zero VA. This causes
link error "Not enough space for ELF and program headers"
llvm-svn: 282067
It is not only a bit more straightforward now, but also next 2 issues are solved:
* It just crashed on ".foo : { *(EXCLUDE_FILE (*file1.o)) }" before.
* It accepted multiple EXCLUDE_FILEs in a row.
Differential revision: https://reviews.llvm.org/D24726
llvm-svn: 282060
This surfaced again with Rust. As per bug 30435, rustc creates a
mergeable section with a sh_entsize zero. It bit us before, too.
I think we should relax the input check rather than being too picky.
Differential Revision: https://reviews.llvm.org/D24789
llvm-svn: 282049
This reverts commit r282021, bringing back r282015.
The problem was that the comparison function was not a strict weak
ordering anymore, which this patch fixes.
Original message:
Only restrict order if both sections are in the script.
This matches gold and bfd behavior and is required to handle some scripts.
The script has to assume where PT_LOADs start in order to align that
spot. If we don't allow section it doesn't know about to move to the
middle, we can need more PT_LOADs and those will not be aligned.
llvm-svn: 282035
This matches gold and bfd behavior and is required to handle some scripts.
The script has to assume where PT_LOADs start in order to align that
spot. If we don't allow section it doesn't know about to move to the
middle, we can need more PT_LOADs and those will not be aligned.
llvm-svn: 282015
This is particularly important when the symbol comes from a linker
script. It is common to use the same linker script for shared
libraries and executables. Without this we would always fail to link
shared libraries with -z,defs and a linker script with an ENTRY
directive.
llvm-svn: 281989
Linker scripts are responsible for aliging '.'. Since they are
designed for bfd which has no --rosegment, they don't align the RO to
RX transition.
llvm-svn: 281978
In most cases that means just not checking the address when we don't
need it.
For some tests it is easier to just set . to a known value.
llvm-svn: 281976
InputSection<ELFT>::Discarded has no name and it's not backed by
a file. Trying to report it as discared will cause a nullptr
dereference, therefore a crash. Skip it.
Differential Revision: https://reviews.llvm.org/D24731
llvm-svn: 281946
The InputSection variables in the Writer were named `C`. This
was because when the ELF linker was ported (from COFF)
the name `Chunks` for input sections was retained.
Luckily we switched to a more ELF-compliant jargon, but these
variables weren't reanamed accordingly during the transition.
llvm-svn: 281917
Will Dietz found and reported that lld does not compile with gcc 6.2.0,
more details https://llvm.org/bugs/show_bug.cgi?id=30438
And confirmed this change fixes the issue.
llvm-svn: 281900
Previously it used llvm-readobj -s, now changed to llvm-objdump -section-headers,
that reduced the output significantly and helps to read/support it.
llvm-svn: 281832
Our implementation supported integer value previously.
ld can use expression,
for example, it is OK to write
. = SEGMENT_START("foobar", .);
Patch implements that.
llvm-svn: 281831
It was possible situation about some commands just were not processed
(were skipped) because of a bug appeared when constraint checking used.
Testcase is attached.
llvm-svn: 281818
This matches gold and bfd, and is pretty much required by some linker
scripts. They end with commands like
foo 0 : { *(bar) }
if we put any SHF_ALLOC sections after they can have an address that
is too low.
llvm-svn: 281778
This matches bfd behavior. It also makes future changes simpler as we
don't have to worry about ignoring these commands in multiple places
llvm-svn: 281775
With fix for 2 bots. Details about the fix performed is on a review page.
Initial commit message:
This is PR30387:
From PR description:
We fail to parse
SECTIONS
{
foo :
{
*(sec0 EXCLUDE_FILE (zed1.o) sec1 EXCLUDE_FILE (zed2.o) sec2 )
}
}
The semantics according to bfd are:
Include sec1 from every file but zed1.o
Include sec2 from every file but zed2.o
Include sec0 from every file
Patch implements the support.
Differential revision: https://reviews.llvm.org/D24650
llvm-svn: 281754
This fixes pr30367, but more importantly, it changes how we compute offsets.
Now offset computation in a walk over linker script commands, like the
rest of assignAddresses. IMHO this is simpler to understand and if we
ever have to create multiple outputsections or chunks to change how we
handle test/ELF/linkerscript/alternate-sections.s it should be easier
to do it.
llvm-svn: 281736
This is PR30387:
From PR description:
We fail to parse
SECTIONS
{
foo :
{
*(sec0 EXCLUDE_FILE (zed1.o) sec1 EXCLUDE_FILE (zed2.o) sec2 )
}
}
The semantics according to bfd are:
Include sec1 from every file but zed1.o
Include sec2 from every file but zed2.o
Include sec0 from every file
Patch implements the support.
Differential revision: https://reviews.llvm.org/D24650
llvm-svn: 281721
test/COFF/rsds.test checks only RSDS directory in a DLL and
didn't check the validity of the PDF file produced.
(Technically the produced PDB is not valid because it is really
a stub, but this test is still good to have.)
llvm-svn: 281678
This is PR30386,
SORT_BY_INIT_PRIORITY is a keyword can be used to sort sections by numerical value of the
GCC init_priority attribute encoded in the section name.
Differential revision: https://reviews.llvm.org/D24611
llvm-svn: 281646
Previouly bot was failing:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/413/steps/test-stage1-compiler/logs/stdio
Fixed possible segfault, so commit should bix the buildbot.
Initial commit message:
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281605
--section-start=sectionname=org
Locate a section in the output file at the absolute address given by org.
You may use this option as many times as necessary to locate multiple sections in the command line.
org must be a single hexadecimal integer; for compatibility with other linkers,
you may omit the leading `0x' usually associated with hexadecimal values.
Note: there should be no white space between sectionname, the equals sign (“<=>”), and org.
-Tbss=org
-Tdata=org
-Ttext=org
Same as --section-start, with .bss, .data or .text as the sectionname.
Differential revision: https://reviews.llvm.org/D24294
llvm-svn: 281458
Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.
I think we don't have to transfer ownership just to free all
instance at once on exit.
In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.
Differential Revision: https://reviews.llvm.org/D24493
llvm-svn: 281425
Something broked BBots:
281318 failed on step 9:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/413
r281317 built step 9 green:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/415
Initial revision commits were:
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281411
Without this flag set, an AArch64 Linux kernel won't try to load the executable
(even if a 32 bit arm kernel will run the binary just fine).
Patch by Martin Storsjö!
Differential revision: https://reviews.llvm.org/D24471
llvm-svn: 281394
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281318
Summary: This test fails if you're building with BUILD_SHARED_LIBS because the LLVM libraries are found via @rpath. Symlinking instead of copying should be sufficiently robust for the test case.
Reviewers: llvm-commits
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D24476
llvm-svn: 281271
Similarly to what was done in r280791 for llvm/.
This should fix a bunch of failures I saw while
trying a BUILD_SHARED_LIBS build on MacOS.
Still there are some failures, but this is a step
forward.
Thanks a lot to Chris Bieneman for the suggested
fix (in PR30345)
llvm-svn: 281256
Having two directories with the same name modulo case does not work well
on Windows. The new test/elf directory was added in r281108. I assume
the intention was to add the test file to the existing test/ELF dir.
llvm-svn: 281115
Implemented by building an ELF file in memory.
elf, default, and binary match gold behavior.
Differential Revision: https://reviews.llvm.org/D24060
llvm-svn: 281108
Although the GUID seems to be stable across test runs now, it seems to be
unstable across hosts. Lets be a bit more lax about the reading of the RSDS
record.
llvm-svn: 281083
Change the way we calculate the build id to use MD5 to give reproducible build
ids. Previously we would generate random bytes for the build id GUID.
llvm-svn: 281079
Fixed code that was not checked before on windows for me, because of testcases that are
disabled on that platform atm.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281049
Fixed code that was not checked by testcases that are disabled on windows.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281045
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281038
Usually, options that are longer than one character can be preceded
either by "-" or "--", but options starting with "o" are exceptions
because they conflict with "-o" option. They have to be preceded by
"--".
llvm-svn: 281004
We still have to skip a token inside SEARCH_DIR() when -nostdlib is
specified. Previuosly, we didn't skip it, so it caused a parse error.
llvm-svn: 281001
lld differs from GNU ld in that it does not have a built-in default
target emulation. Emulation is always specified via the -m option, or
obtained from the object file(s) being linked. In most cases at least
one ELF object is included in the link, so the emulation is known.
When using lld's (not yet committed) -b binary support with -r, to
convert a binary file into an ELF object we do not have a known
emulation. The error message previously emitted in this case
"-m or at least a .o file required" is accurate but does not offer
much insight. Add text to the error message to give a hint why -m or an
object file is required.
Differential Revision: https://reviews.llvm.org/D24348
llvm-svn: 280989
A trailing _fbsd is stripped from emulation names, but if the result was
still not a valid emulation the error was somewhat confusing.
For example,
% ld.lld -m elf_amd64_fbsd
unknown emulation: elf_amd64
Use the original emulation name in error messages.
Differential Revision: https://reviews.llvm.org/D24357
llvm-svn: 280983
In the FreeBSD world x86_64 still has its original name, amd64. Accept
it as an alias.
Differential Revision: https://reviews.llvm.org/D24356
llvm-svn: 280982
This simplifies error handling as there is now only one place in the
code that needs to consider the possibility that the name is
corrupted. Before we would do it in every access.
llvm-svn: 280937
Absence of it caused a clang warning:
warning: 'lld:🧝:LinkerScriptBase' has virtual functions but non-virtual destructor [-Wnon-virtual-dtor]
At fact we don't need it here because do not destroy this object by
base pointer.
llvm-svn: 280916
This patch allows static linking of TLS code. To do that it fixes
GOT entries initialization.
If TLS-related GOT entry created for a preemptible symbol i.e. has
a corresponding dynamic relocation, leave the entry initialized by zero.
Write down adjusted TLS symbol's values otherwise. For the adjustments
calculation use offsets for thread-local storage.
https://www.linux-mips.org/wiki/NPTL
llvm-svn: 280914
Previous way of accessing templated methods was a bit bulky,
Patch introduces small interface based solution.
Differential revision: https://reviews.llvm.org/D23872
llvm-svn: 280910
GCC passes it by default on powerpc64 on FreeBSD. GNU ld claims "this
option is ignored for SVR4 compatibility", so we can ignore it too.
Differential Revision: https://reviews.llvm.org/D24313
llvm-svn: 280864
After r280733 we use LLVM's demangler in lld. As a result we no longer
have a discrepancy between f() and f(void) on FreeBSD (due to an issue
with FreeBSD's system demangler).
Restore a test case for a void arg function.
Differential Revision: https://reviews.llvm.org/D24305
llvm-svn: 280831
Previously we combined sections by name if linkerscript was used.
For that we had to disable SHF_MERGE handling temporarily, but then
found that implementing it properly will require additional complexity layers like
subsections or something.
At the same time looks we can live with multiple output sections approach for now.
That patch do this change.
Differential revision: https://reviews.llvm.org/D24127
llvm-svn: 280801
GNU ld supports [chars] wildcards in version scripts, to match a single instance of any of the chars.
Here is an extern example from libstdc++'s version script in FreeBSD:
extern "C++"
{
...
std::locale::_[T-Za-z]*;
std::[A-Zm]*;
std::n[^u]*;
std::nu[^m]*;
std::num[^e]*;
...
}
Patch adds support for scripts above. This is PR29093.
Differential revision: https://reviews.llvm.org/D23803
llvm-svn: 280799
Previously testcases were enabled only for shell.
r280733 added c++ itanium demangler to lld and we can enable them fully.
Also this change make quotes to be escaped:
extern "C++" -> extern \"C++\", which worked before just because we are dropping tokens
quotes internally at this moment.
llvm-svn: 280797
George Rimar