LLD's error messages contain line numbers, function names or section names.
Currently they are formatter as follows.
foo.c (32): symbol 'foo' not found
foo.c (function bar): symbol 'foo' not found
foo.c (.text+0x1234): symbol 'foo' not found
This patch changes them so that they are consistent with Clang's output.
foo.c:32: symbol 'foo' not found
foo.c:(function bar): symbol 'foo' not found
foo.c:(.text+0x1234): symbol 'foo' not found
Differential Revision: https://reviews.llvm.org/D26901
llvm-svn: 287537
GNU linkers disagree here.
Though both -version and -v are mentioned
in help to print the version information, GNU ld just normally exits,
while gold can continue linking. We are compatible with ld.bfd here.
This fixes PR31057.
Differential revision: https://reviews.llvm.org/D26865
llvm-svn: 287448
Since the output has a section table too, it is meaningful to compute
the sh_link. In a more practical note, the binutils' strip crashes if
sh_link is not set for SHT_ARM_EXIDX.
llvm-svn: 287280
I hit an internal linker script that was defining _DYNAMIC instead of
letting the linker do it. It turns out that both bfd and gold allow
that.
This is pretty easy to implement, just make the linker defined symbol
weak. This should have no impact in the case where there is no user
defined symbol: The visibility is hidden, which causes the output to
still be local.
llvm-svn: 287260
Linker script doesn't create a section if it has no content. So the following
script doesn't create .norelocs section if it doesn't have any .rel* sections.
.norelocs : { *(.rel*) }
Later, if you assert that the size of .norelocs is 0, LLD printed out
an error message, because it didn't allow calling SIZEOF() on nonexistent
sections.
This patch allows SIZEOF() on nonexistent sections, so that you can do
something like this.
ASSERT(SIZEOF(.norelocs), "shouldn't contain .rel sections!")
Note that this behavior is compatible with GNU.
Differential Revision: https://reviews.llvm.org/D26810
llvm-svn: 287257
Apparently this is wrong because it's legal to have a filename
on UNIX which contains a backslash.
Differential Revision: https://reviews.llvm.org/D26734
llvm-svn: 287143
Our build-id is a tree hash anyway, so I'll define this as a synonym
for sha1. GNU gold takes this parameter, so this is for compatibility
with that.
llvm-svn: 287119
This patch stops creating symbols like __ehdr_start,
_end/_etext_edata,__tls_get_addr when using -r.
This fixes PR30984.
Differential revision: https://reviews.llvm.org/D26600
llvm-svn: 286941
Patch adds a filename to that error message.
I faced next error when debugged one of FreeBSD port:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol __tls_get_addr
error message was poor and this patch improves it to show the locations
of symbol declaration and using.
Differential revision: https://reviews.llvm.org/D26508
llvm-svn: 286940
Found this when tried to link lang/ccl FreeBSD port.
Issue is very close to D23201.
This is the reason of lang/ccl port link fail.
GNU assembler 2.17.50 [FreeBSD] 2007-07-03 could generate broken objects,
where notype symbols are associated with symtab:
...
[ 9] .symtab SYMTAB 0000000000000000 00003c78
0000000000006858 0000000000000018 10 803 8
...
192: 000000000000000d 0 NOTYPE LOCAL DEFAULT 9 _cons_org
Patch allows to handle such objects.
Differential revision: https://reviews.llvm.org/D26613
llvm-svn: 286939
Propagate program headers by walking the commands, not the
sections. This allows us to propagate program headers even from
sections that don't end up in the output.
Fixes pr30997.
llvm-svn: 286837
Previously we did not support anything except "local: *", patch changes that.
Actually GNU rules of proccessing wildcards are more complex than that (http://www.airs.com/blog/archives/300):
There are 2 iteration for wildcards, at first iteration "*" wildcards are ignored and handled at second iteration.
Since we previously decided not to implement such complex rules,
I suggest solution that is implemented in this patch. So for "local: *" case nothing changes,
but if we have wildcarded locals,
they are processed before wildcarded globals.
This should fix several FreeBSD ports, one of them is jpeg-turbo-1.5.1 and
currently blocks about 5k of ports.
Differential revision: https://reviews.llvm.org/D26395
llvm-svn: 286713
Unlike gold, bfd, gas or MC we were putting exidx sections first since
they are ro.
The spec doesn't explicitly say that they must come after, but it is
definitely more convenient for the consumer, matches other producers
and matches other areas in ELF (like SHT_GROUP) where sections are
ordered in a natural way.
llvm-svn: 286659
We would create a MergeInputSection for the synthetic .comment and
crash trying to add it to a regular output section.
With this we just don't add the synthetic section with -r. That is
consistent with gold that doesn't create .note.gnu.gold-version with
-r.
llvm-svn: 286635
Summary:
This patch adds a ".comment" section to an output. The comment
section contains the linker's version string. You can now
find out whether a binary is created by LLD or not using objdump
command like this.
$ objdump -s -j .comment foo
foo: file format elf64-x86-64
Contents of section .comment:
0000 00474343 3a202855 62756e74 7520342e .GCC: (Ubuntu 4.
0010 382e342d 32756275 6e747531 7e31342e 8.4-2ubuntu1~14.
...
00c0 766d2f74 72756e6b 20323835 38343629 vm/trunk 285846)
00d0 004c696e 6b65723a 204c4c44 20342e30 .Linker: LLD 4.0
00e0 2e302028 7472756e 6b203238 36343036 .0 (trunk 286406
00f0 2900 ).
Compilers emits .comment section as well, so the output contains
both compiler and linker information.
Alternative considered:
I first tried to add a SHT_NOTE section because GNU gold does that.
A NOTE section starts with a header which contains content type.
It turned out that ld.gold sets type NT_GNU_GOLD_VERSION to their
NOTE section. So the NOTE type is only for GNU gold (surprise!)
Next, I tried to create ".linker-version" section. However, it seems
that reusing the existing ".comment" section is better because 1)
other tools already know about .comment section and is able to strip
it and 2) the result contans not only linker info but also compiler
info.
Differential Revision: https://reviews.llvm.org/D26487
llvm-svn: 286496
In a non-LTO build is a nop. In a LTO build, we deallocate/destroy
managed static and this allows us to get the output of, e.g.,
-time-passes without performing a full shutdown.
Differential Revision: https://reviews.llvm.org/D26517
llvm-svn: 286493
Relocations are the last thing that we wore storing a raw section
pointer to and parsing on demand.
With this patch we parse it only once and store a pointer to the
actual data.
The patch also changes where we store it. It is now in
InputSectionBase. Not all sections have relocations, but most do and
this simplifies the logic. It also means that we now only support one
relocation section per section. Given that that constraint is
maintained even with -r with gold bfd and lld, I think it is OK.
llvm-svn: 286459
Patch allows to pass a symbols file to linker.
LLD will map symbols to sections and sort sections
in output according to symbol ordering file.
That can help to reduce the startup time and/or
amount of pagefaults during startup.
Also, interesting benchmark result was produced by Rafael Espíndola.
After applying the symbols file for clang he timed compiling
X86MCTargetDesc.ii to an object file.
The page faults went from just
56,988 to 56,946 since most faults are not in the binary.
Running time went from 4.403053515 to 4.178112244.
The speedup seems to be because of better cache
locality.
Differential revision: https://reviews.llvm.org/D26130
llvm-svn: 286440
Previously, we have both input and output section for .MIPS.abiflags.
Now we have only one class for .MIPS.abiflags, which is MipsAbiFlagsSection.
This class is a synthetic input section.
.MIPS.abiflags sections are handled as regular sections until
the control reaches Writer. Writer then aggregates all sections
whose type is SHT_MIPS_ABIFLAGS to create a single synthesized
input section. The synthesized section is then processed normally
as if it came from an input file.
llvm-svn: 286398
Previously, we have both input and output sections for .reginfo and
.MIPS.options. Now for each such sections we have one synthetic input
sections: MipsReginfoSection and MipsOptionsSection respectively.
Both sections are handled as regular sections until the control reaches
Writer. Writer then aggregates all sections whose type is SHT_MIPS_REGINFO
or SHT_MIPS_OPTIONS to create a single synthesized input section. In that
moment Writer also save GP0 value to the MipsGp0 field of the corresponding
ObjectFile. This value required for R_MIPS_GPREL16 and R_MIPS_GPREL32
relocations calculation.
Differential revision: https://reviews.llvm.org/D26444
llvm-svn: 286397
The ARM 32 and 64-bit ABI does not use 0 for undefined weak references
that are used in PC relative relocations. In particular:
- A branch relocation to an undefined weak resolves to the next
instruction. Effectively making the branch a no-op
- In all other cases the symbol resolves to the place so that S + A - P
resolves to A.
Differential Revision: https://reviews.llvm.org/D26240
llvm-svn: 286353
Patch switches computing of --build-id hash to tree.
This is the way when input data is splitted by chunks,
hash is computed for each one in threaded/non-threaded way.
At the end hash is conputed for result tree.
With or without -threads the result hash is the same.
Differential revision: https://reviews.llvm.org/D26199
llvm-svn: 286061
A CommonInputSection is a section containing all common symbols.
That was an input section but was abstracted in a different way
than the synthetic input sections because it was written before
the synthetic input section was invented.
This patch rewrites CommonInputSection as a synthetic input section
so that it behaves better with other sections.
llvm-svn: 286053
In short the patch introduces support for linking object file conform
MIPS N32 ABI [1]. This ABI is similar to N64 ABI but uses 32-bit
pointer size.
The most non-trivial requirement of this ABI is one more relocation
packing format. N64 ABI puts multiple relocation type into the single
relocation record. The N32 ABI uses series of successive relocations
with the same offset for this purpose. In this patch, new function
`mergeMipsN32RelTypes` handle this case and "convert" N32 relocation to
the N64 relocation so the rest of the code keep unchanged.
For now, linker does not support series of relocations applied to sections
without SHF_ALLOC bit. Probably later I will add the support or insert
some sort of assert into the `relocateNonAlloc` routine to catch this
case.
[1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/MIPS-N32-ABI-Handbook.pdf
Differential revision: https://reviews.llvm.org/D26298
llvm-svn: 286052
This change fixes a bug that was introduced by r285851.
r285851 converted .interp section as an output section to an input
section. But I forgot to make it a "Live" section, so if -gc-section
is given, it was garbage collected.
llvm-svn: 286025
An undefined weak reference is given an address of 0 this will
incorrectly trigger the creation of a Thumb to ARM interworking Thunk
if there is a Thumb branch instruction to the symbol. This results in
an error as Thunks only make sense to defined or shared symbols.
We prevent this by detecting an undefined symbol and not creating a thunk
for it.
Differential Revision: https://reviews.llvm.org/D26239
llvm-svn: 285896
When we have SHT_GNU_versym section, it is should be associated with symbol table
section. Usually (and in out implementation) it is .dynsym.
In case when .dynsym is absent (due to broken object for example),
lld crashes in parseVerdefs() when accesses null pointer:
Versym = reinterpret_cast<const Elf_Versym *>(this->ELFObj.base() +
VersymSec->sh_offset) +
this->Symtab->sh_info;
DIfferential revision: https://reviews.llvm.org/D25553
llvm-svn: 285796
Previously, we added strings from DynamicSection::finalize().
It was a bit tricky because finalize() is supposed to fix the final
size of the section, but adding new strings would change the size of
.dynstr section. So there was a dependency between finalize functions
of .dynamic and .dynstr.
However, I noticed that we can elimiante the dependency by simply
add strings early; we don't have to do that in finalize() but can do
from DynamicSection's ctor.
This patch defines a new function, DynamicSection::addEntries, to
add .dynamic entries that doesn't depend on other sections.
llvm-svn: 285784
The example reported in PR30793 shows a case where gc reclaims
a SHF_TLS section, but it doesn't reclaim the section containing
the debug info for it.
This is expected, as we do not reclaim non-alloc sections
during the garbage collection phase (and this is not going to
change anytime soon, at least this is what I gathered last I
talked with Rafael about it).
So, we end up with a pending reference, thinking that the input
was invalid (which is not true, as it's GC that removed the
SHT_TLS section, and therefore didn't create the PT_TLS *segment*
for it). In cases like this, just assign a VA of zero at relocation
time instead of error'ing out (this is what gold does as well, FWIW).
Differential Revision: https://reviews.llvm.org/D26201
llvm-svn: 285735
With this patch we keep track of the fact that . is a position in the
file and therefore not absolute. This allow us to compute relative
relocations that involve symbol that are defined in linker scripts
with '.'.
This fixes https://llvm.org/bugs/show_bug.cgi?id=30406
There is still more work to track absoluteness over the various
expressions, but this should unblock linking the EFI bootloader.
llvm-svn: 285641
We parse linker scripts very early, but whether an expression is
absolute or not can depend on a symbol defined in a .o. Given that, we
have to delay the computation of IsAbsolute. We can do that by storing
an AST when parsing or by also making IsAbsolute a function like we do
for the expression value. This patch implements the second option.
llvm-svn: 285628
And as a token of the new feature, make ALIGNOF always absolute.
This is a step in making it possible to have non absolute symbols out
of output sections.
llvm-svn: 285608
This fixes pr30803 by not relaxing that particular access. We could
also let adjustRelaxExpr know that the target is absolute so that it
uses R_RELAX_GOT_PC_NOPIC, but it is not clear if it is worth it.
llvm-svn: 285317
When static linking in ARM (like Mips) __tls_get_addr is defined by
the library so we should not define it as a synthetic.
We also need to add __exidx_start and __exidx_end for the .ARM.exidx
section as the static libc library startup code is expecting them to
be defined by the default linker script for static linking on ARM.
Differential revision: https://reviews.llvm.org/D25978
llvm-svn: 285279
As the state of lld gets more complicated, shutting down gets more
expensive.
In a normal lld run we can just call _exit immediately after renaming
the temporary output file. We still want the ability to run a full
shutdown since that is useful for detecting memory leaks.
This patch adds a --full-shutdown flag and changes lit to use it.
llvm-svn: 285224
This patch make lld show following details for undefined symbol errors:
- file (line)
- file (function name)
- file (section name + offset)
Differential revision: https://reviews.llvm.org/D25826
llvm-svn: 285186
We were previously using the (static) addSynthetic function to create
*_start/*_end symbols. This function was doing almost the same thing as
addOptionalSynthetic, except that it would also create the symbol in the
case where it is unreferenced. Because the symbol has hidden visibility,
creating it in that case would have no effect other than adding another
entry to the static symbol table. Remove addSynthetic and change callers to
use addOptionalSynthetic instead.
Differential Revision: https://reviews.llvm.org/D25545
llvm-svn: 285021
When doing a relocatable link the .ARM.exidx sections with the
SHF_LINK_ORDER flag set need to set the sh_link field to the executable
section they describe. We find the appropriate OutputSection by
following the sh_link field of the .ARM.exidx InputSections.
The getOutputSectionName() function rules make sure that when there are
multiple .ARM.exidx InputSections in an OutputSection they all have the
same sh_link field.
Differential revision: https://reviews.llvm.org/D25825
llvm-svn: 284820
Some MIPS relocations used to access GOT entries are able to manipulate
16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle
32-bit indexes. 16-bit relocations are generated by default. The 32-bit
relocations are generated by -mxgot flag passed to compiler. Usually
these relocation are not mixed in the same code but files like crt*.o
contain 16-bit relocations so even if all "user's" code compiled with
-mxgot flag a few 16-bit relocations might come to the linking phase.
Now LLD does not differentiate local GOT entries accessed via a 16-bit
and 32-bit indexes. That might lead to relocation's overflow if 16-bit
entries are allocated to far from the beginning of the GOT.
The patch introduces new "part" of MIPS GOT dedicated to the local GOT
entries accessed by 32-bit relocations. That allows to put local GOT
entries accessed via a 16-bit index first and escape relocation's overflow.
Differential revision: https://reviews.llvm.org/D25833
llvm-svn: 284809
Summary:
The rules for quoting the command line that a subprocess receives are
user space conventions implemented by the C runtime. Python's quoting
rules are implemented here:
c30098c8c6/Lib/subprocess.py (L725)
The result is that the final command line C string computed by Python is
'echo \"'. Mingw doesn't appear to interpret that backslash as escaping
the quote because it is not already inside a quoted region. As a result,
our echo command prints a single backslash instead of a quote.
The whole issue can be sidestepped by adding a space a forcing Python to
put the argument to echo in double quotes.
Reviewers: inglorion, ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25841
llvm-svn: 284768
This is needed for the following case (OpenCL example):
__global int Var = 0;
__global int* Ptr[] = {&Var};
...
Differential Revision: https://reviews.llvm.org/D25815
llvm-svn: 284764
The R_ARM_PREL31 and R_ARM_NONE relocations should not be faulted in
shared libraries. In the case of R_ARM_NONE, we have moved the TLS
relaxation hint instruction to R_TLSDESC_CALL so that R_HINT can be used
without side-effects. In the case of R_ARM_PREL31 we permit it to be used
against PLT entries as the personality routines are imported when used in
shared libraries.
Differential Revision: https://reviews.llvm.org/D25721
llvm-svn: 284710
This script below shouldn't include file and program headers
to PT_LOAD segment, because it doesn't have PHDRS and FILEHDR
attributes:
PHDRS { all PT_LOAD; }
SECTIONS { /* list of sections here */ }
Differential revision: https://reviews.llvm.org/D25774
llvm-svn: 284709
In this patch partial gdb_index section is created.
For costructing the .gdb_index section 6 steps should be performed (details are in
SplitDebugInfo.cpp file header), this patch do first 3:
Creates proper section header.
Fills list of compilation units.
Types CU list area is not supposed to be supported, so it is ignored and therefore
can be treated as implemented either.
Differential revision: https://reviews.llvm.org/D24706
llvm-svn: 284708
-format=<foo>, -format <foo> and -b <foo> are all the same.
Previous code was intended to produce an error message with the
same spelling as given from the command line, but it actually
always printed out this string: "unknown -format= value:".
This is probably more confusing than "unknown -format value:".
So I changed the message.
llvm-svn: 284693
Previously, we were checking the existence of an entry symbol
too early. It was done before the linker script processor creates
symbols defined in scripts. Fixes bug 30743.
llvm-svn: 284676
Linker scripts may specify PHDRS, but not specify section to
segment assignments, i.e:
PHDRS { seg PT_LOAD; }
SECTIONS {
.sec1 {} : seg
.sec2 {}
}
In such case linker should still choose some segment for .sec2 section.
This patch will add .sec2 to previously opened segments (seg) or to the
very first PT_LOAD segment, if no section-to-segment assignments has been
made
Differential revision: https://reviews.llvm.org/D24795
llvm-svn: 284600
Both gold and ld accepts integers instead of named constants
for PHDRS.
Patch adds support for that.
Differential revision: https://reviews.llvm.org/D25549
llvm-svn: 284470
The R_ARM_TARGET2 relocation is used in ARM exception tables to encode
a data dependency that will only be dereferenced by code in the
run-time support library. In a similar way to R_ARM_TARGET1 the
handling of the relocation is target specific, it maps to one of
R_ARM_ABS32, R_ARM_REL32 or R_ARM_GOT_PREL. The choice depends on the
run-time library. R_ARM_GOT_PREL is used for linux and BSD,
R_ARM_ABS32 and R_ARM_REL32 are used for bare-metal.
The command line option --target2=<target> can be used to select the
relocation used for R_ARM_TARGET2. The default is R_ARM_GOT_PREL.
Differential revision: https://reviews.llvm.org/D25684
llvm-svn: 284404
In continue of D25555, this patch fixes possible crash when
we have multiple SHT_MIPS_REGINFO or SHT_MIPS_ABIFLAGS sections.
yaml2obj was used to produce such objects.
Differential revision: https://reviews.llvm.org/D25609
llvm-svn: 284376
It was requested on review for https://reviews.llvm.org/D25090 to add testcase in lld.
Spec says (http://www.sco.com/developers/gabi/1998-04-29/ch4.eheader.html) :
e_shnum
This member holds the number of entries in the section header table.
Thus the product of e_shentsize and e_shnum gives the section header table's size in bytes.
If a file has no section header table, e_shnum holds the value zero.
In case revealed, broken input did not contain zero in this field.
LLD then could crash when proccessed sections (returned array has incorrect size):
template <class ELFT> void SharedFile<ELFT>::parseSoName() {
...
for (const Elf_Shdr &Sec : Obj.sections()) {
...
llvm-svn: 284375
This is 30646.
PT_OPENBSD_RANDOMIZE
The array element specifies the location and size of a part of the memory image of the program that must be filled with random data before any code in the object is executed. The memory region specified by a segment of this type may overlap the region specified by a PT_GNU_RELRO segment, in which case the intersection will be filled with random data before being marked read-only.
Reference links:
http://man.openbsd.org/OpenBSD-current/man5/elf.5c494713c45
Differential revision: https://reviews.llvm.org/D25469
llvm-svn: 284234
Issue was revealed by AFl and I was able to generate such object using yaml2obj.
When object has more than one SHT_MIPS_OPTIONS,
each except the last one is destroyed after placing into Sections array.
Sections array contains dead pointers finally. LLD may crash then.
Differential revision: https://reviews.llvm.org/D25555
llvm-svn: 284227
-z wxneeded creates a PHDR PT_OPENBSD_WXNEEDED.
PT_OPENBSD_WXNEEDED
The array element specifies that a process executing this file may need to be able to map or protect memory regions as simultaneously executable and writable. If the system is unable or unwilling to permit that for this executable then it may fail immediately. This segment type is meaningful only for executable files and is ignored in other objects.
http://man.openbsd.org/OpenBSD-current/man5/elf.5
Differential revision: https://reviews.llvm.org/D25472
llvm-svn: 284226
Previously we would fail to synthesise a __start_ or __stop_ symbol if
there existed a definition in a DSO. Instead, we would try to link against
the DSO definition. This became possible after D23552 when linking against
lld-produced DSOs but could in principle also occur when linking against
DSOs produced by other linkers.
Not only does it seem more likely that a user would expect the resolved
definition to be local to the executable, but if a __start_ or __stop_
symbol was synthesised by the linker, it is effectively impossible to link
against correctly from a non-PIC executable in a read-only section. Neither
a PLT nor a copy relocation would give us the right semantics here. The only
way the link could succeed is if the executable provided its own synthetic
definition of the symbol.
The fix is to also synthesise the definition if the only definition comes
from a DSO. Since this is what the addOptionalSynthetic function does,
switch to using that function.
Fixes PR30680.
Differential Revision: https://reviews.llvm.org/D25544
llvm-svn: 284168
Previously, we supported only SHF_COMPRESSED sections because it's
new and it's the ELF standard. But there are object files compressed
in the GNU style out there, so we had to support it.
Sections compressed in the GNU style start with ".zdebug_" and
contain different headers than the ELF standard's one. In this
patch, getRawCompressedData is responsible to handle it.
A tricky thing about GNU-style compressed sections is that we have
to rename them when creating output sections. ".zdebug_" prefix
implies the section is compressed. We need to rename ".zdebug_"
".debug" because our output sections are not compressed.
We do that in this patch.
llvm-svn: 284068
r283984 introduced a problem of too many warning messages being shown
when -ffunction-sections and -fdata-sections were used in conjunction
with --gc-sections linker flag and debugging information present. This
happens because lot of relocations from .debug_line section may become
invalid in such case. The newer fix doesn't show any warning message but
zeroes OutSec pointer in createInputSectionList() to avoid crash, when
relocations are written
llvm-svn: 284010
This part was splitted from D25016.
When sh_info value was set in the way that non-local symbol was treated as local, lld
was asserting, patch fixes that.
Differential revision: https://reviews.llvm.org/D25371
llvm-svn: 283859
Before the default was whatever number hardware_concurrency() returned.
Users can specify the number of threads via --lto-jobs=X option.
llvm-svn: 283787
Sometimes the very first PT_LOAD segment, created by lld, can be empty.
This happens when (all conditions met):
- Linker script is used
- First section in ELF image is not RO
- Not enough space for program headers.
Differential revision: https://reviews.llvm.org/D25330
llvm-svn: 283760
With fix: commit changes from InputFiles.cpp too.
Original commit message:
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283738
.ARM.exidx sections have a reverse dependency on the section they have
a SHF_LINK_ORDER dependency on. In other words a .ARM.exidx section is
live only if the executable section it describes is live. We implement
this with a reverse dependency field in InputSection.
Adding the dependency to InputSection is the simplest implementation
but it could be moved out to a separate map if it were found to decrease
performance for non ARM targets.
Differential revision: https://reviews.llvm.org/D25234
llvm-svn: 283734
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283733
Absolute local symbols with name staring from ".L" were reason of crash.
The same could happen when using some broken inputs found by AFL.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D25365
llvm-svn: 283731
The .ARM.exidx sections contain a table. Each entry has two fields:
- PREL31 offset to the function the table entry describes
- Action to take, either cantunwind, inline unwind, or PREL31 offset to
.ARM.extab section
The table entries must be sorted in order of the virtual addresses the
first entry of the table describes. Traditionally this is implemented by
the SHF_LINK_ORDER dependency. Instead of implementing this directly we
sort the table entries post relocation.
The .ARM.exidx OutputSection is described by the PT_ARM_EXIDX program
header
Differential revision: https://reviews.llvm.org/D25127
llvm-svn: 283730
When sh_info of sumbol table value was set to zero, lld was asserting.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25016
llvm-svn: 283562
I found that this check still may be useful in some cases.
At fact since we use uint32_t alignment, then maximum value
that is valid for us is 0x80000000. But some broken files,
for example file from testcase may have greater value.
Because of that offset calculation overflow and crash happens.
Differential revision: https://reviews.llvm.org/D25324
llvm-svn: 283544
Previously if sh_size of dynamic section was broken,
lld may crash. Or even may not crash if used 32 bits host.
(then value may be truncated to 32 bits when doing pointer arithmetic
and could be just zero).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25327
llvm-svn: 283533
createELFObj() may call error(...), for example when file is too short.
In that case header is not set and following line lead to crash:
EMachine = ELFObj.getHeader()->e_machine;
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25233
llvm-svn: 283532
This patch makes the check for null section stricter,
so it is only allowed for STT_SECTION symbols now.
Differential revision: https://reviews.llvm.org/D25231
llvm-svn: 283426
Do not merge sections if generating a relocatable object. It makes
the code simpler because we do not need to update relocations addends
to reflect changes introduced by merging. Instead of that we write
such "merge" sections into separate OutputSections and keep SHF_MERGE
/ SHF_STRINGS flags and sh_entsize value to be able to perform merging
later during a final linking.
Differential Revision: http://reviews.llvm.org/D25066
llvm-svn: 283300
If we have input without object files, for example if we have only .so
code crashes in checkFlags(), getPicFlags(), getArchFlags() functions.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25237
llvm-svn: 283226
Previously lld would hang in infinite loop in this case,
patch fixes the issue. Object was found during AFL run.
Differential revision: https://reviews.llvm.org/D25229
llvm-svn: 283208
Relative to PR30540.
If .symtab has invalid type in elf, no bodies are created and any relocation
that tries to access them will fail.
The same can happen if symbol index is just incorrect.
This was revealed by "id_000005,sig_11,src_000000,op_flip2,pos_420"
Differential revision: https://reviews.llvm.org/D25025
llvm-svn: 283201
id_000021,sig_11,src_000002,op_flip1,pos_92 from PR30540
does not have TLS sections, but type
of one of the symbol is broken and set to STT_TLS,
what resulted in a crash. Patch fixes crash.
DIfferential revision: https://reviews.llvm.org/D25083
llvm-svn: 283198
Testcase contains a common symbol with zero alignment,
previously lld would crash, patch fixes that.
Differential revision: https://reviews.llvm.org/D25085
llvm-svn: 283197
Follow-up to r282716. Reject input files with non-zero GP0 value only in
case of relocatable object generation. In other case we can handle
arbitrary GP0 value so it does not have a sense to make the restriction
so wide.
llvm-svn: 283194
Case was revealed by id_000010,sig_08,src_000000,op_havoc,rep_4 from PR30540.
Out implementation uses uint32 for storing section alignment value,
what seems reasonable, though if value exceeds 32 bits bounds we have
truncation and final value of 0.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25082
llvm-svn: 283097
Previously, it warned on any archive file that has no symbol.
It turned out that that is too noisy.
With this patch, it warns on such archive file that contains no file.
Differential Revision: https://reviews.llvm.org/D25111
llvm-svn: 282885
We would crash when a non-alloca section pointed to a gced part of a
merge section.
That can happen when a C/c++ constant in put in a merge section and
debug info is present.
llvm-svn: 282845
We were implicitly creating space for the headers. That is not the
behaviour of bfd, which requires the script to use SIZEOF_HEADERS. The
difference is important for scripts that don't use SIZEOF_HEADERS and
expect the first section to be at 0.
llvm-svn: 282818
Currently lld will implicitly reserve space for the headers. This is
not the case is bfd, where it is the script responsibility to use
SIZEOF_HEADERS. This means that a script not using SIZEOF_HEADERS and
expecting the address of the first section to be 0 would fail with lld.
I am fixing that is the next commit. This one just makes the tests
explicitly use SIZEOF_HEADERS to avoid the dependency on the current
behaviour.
llvm-svn: 282814
Since they end up going on the same PT_LOAD, there is no reason to
sort them. This matches bfd's behaviour and is user visible in the
placement of orphan sections.
llvm-svn: 282799
If there is not sufficient address space, just give up and don't put
the header in the PT_LOAD.
This matches bfd behaviour and I found at least one script that
depends on having a section at address 0.
llvm-svn: 282750
LLD does not update relocations addends when generate a relocatable
object. That is why we should not write a non-zero GP0 value into
the .reginfo and .MIPS.options sections. And we should not accept input
object files with non-zero GP0 value because we cannot handle them
properly.
llvm-svn: 282716
In case of linking PIC and non-PIC code together and generation of a
relocatable object, all PIC symbols should have STO_MIPS_PIC flag in the
symbol table of the ouput file.
llvm-svn: 282714
If we two sections reside in the same PT_LOAD segment,
we compute second section using the following formula:
Off2 = Off1 + VA2 - VA1. This allows OS kernel allocating
sections correctly when loading an image.
Differential revision: https://reviews.llvm.org/D25014
llvm-svn: 282705
This subfolder just like "linkerscript" subfolder keeps
testcases with invalid input. According to PR30540 it seems
we might have many new ones soon, so it is seems reasonable to
separate them from regular testcases.
Differential revision: https://reviews.llvm.org/D25010
llvm-svn: 282595
This matches the behavior of Binutils linkers. We also change the
default MaxPageSize on x86-64 to 0x1000 to preserver the current
behavior, which is the same as the behavior implemented by gold.
https://llvm.org/bugs/show_bug.cgi?id=30541
Differential Revision: https://reviews.llvm.org/D24987
llvm-svn: 282560
r282444 introduced new issue, sample program below
fails to link on
assert(Piece.Live);
int main() { return 0; }
clang test.cpp -c -o out.o -g
ld.lld -flavor gnu --gc-sections out.o -o out
Problem is that .debug_info contains relocations to .debug_str:
Section (7) .rela.debug_info {
..
0xC R_X86_64_32 .debug_str 0x0
0x12 R_X86_64_32 .debug_str 0x37
..
But we do not preserve .debug_str in a right way now.
To fix this we should ignore relocations from non-allocatable sections to allocatable
to allow GC work at full power, but still should proccess relocations from non-allocatable to non-allocatable sections
as usual to mark some parts of debug sections alive to keep them so we do not end
up with such assert when trying to access dead pieces. That looks like what gold/ld do, they do
not strip .debug_str section from what I saw using sample provided.
Thanks to Evgeny Leviant for suggestions about how to fix this.
Differential revision: https://reviews.llvm.org/D24967
llvm-svn: 282495
The BYTE, SHORT, LONG, and QUAD commands store one, two, four, and eight bytes (respectively).
After storing the bytes, the location counter is incremented by the number of bytes
stored.
Previously our scripts handles these commands incorrectly. For example:
SECTIONS {
.foo : {
*(.foo.1)
BYTE(0x11)
...
We accepted the script above treating BYTE as input section description.
These commands are used in the wild though.
Differential revision: https://reviews.llvm.org/D24830
llvm-svn: 282429
PR30521 was about linking shared library. After r282295 code when linking -shared produced
"entry symbol not found" warning, what in combination with --fatal-errors failed linkage.
Patch fixes logic (and adds testcases) to follow next rules:
1) If entry was specified and not found report warning.
2) If entry was not specified then:
a) Emit warning if not -shared.
b) Do not emit warning if -shared.
Differential revision: https://reviews.llvm.org/D24913
llvm-svn: 282427
I found out this wasn't tested when looking at Vedant's coverage bot
numbers, so, thanks to him. While I'm here, switch the error message
to be lld-compliant (first letter lowercase).
llvm-svn: 282335
We were counting the size of the bss section holding common symbols twice:
Dot += CurOutSec->getSize();
flush();
The new code is also simpler as now flush is the only function that
inserts in AlreadyOutputOS, which makes sense since the set hold fully
output sections.
llvm-svn: 282285
If we pass --gc-sections to lld and .tbss is not referenced,
the section is reclaimed and lld doesn't create a TLS program header.
R_TLS tries to access the program header -> lld crashes.
Mimic what bfd/gold do in this case and resolve a weak undefined
TLS symbol to the base of the TLS block, i.e. give it a value of zero.
Differential Revision: https://reviews.llvm.org/D24832
llvm-svn: 282279
It would fail for example if the directory contained an @. Both gold
and bfd require quotes for @, so just change the test to quote the
directory name.
Thanks to Vedant Kumar for the bug report.
llvm-svn: 282256
The ARM TLS relocations are placed on literal data and not the
code-sequence, it is therefore not possible to implement the relaxTls*
functions. This change updates handleMipsTlsRelocation() to
handleNoRelaxTlsRelocation() and incorporates ARM as well as Mips.
The ARM support in handleNoRelaxTlsRelocation() currently needs to ouput
the module index dynamic relocation in all cases as it is relying on the
dynamic linker to set the module index in the got.
Should address PR30218
Differential Revision: https://reviews.llvm.org/D24827
llvm-svn: 282250
Previously we failed to parse next scripts because disallowed
a space between filler value and '=':
.text : {
...
} :text = 0x9090
Differential revision: https://reviews.llvm.org/D24831
llvm-svn: 282248
DEFINED(symbol)
Return 1 if symbol is in the linker global symbol table and is defined before
the statement using DEFINED in the script, otherwise return 0.
Can be used to define default values for symbols. Found it in the wild.
Differential revision: https://reviews.llvm.org/D24858
llvm-svn: 282245
If section contains local symbols ldd crashes, because local
symbols are added to symbol table before section is discarded
by linker script processor. This patch calls copyLocalSymbols()
after createSections, so discarded section symbols are not copied
llvm-svn: 282244
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
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
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
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
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
Eugene Leviant