This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
```
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
```
Manual has next description:
//
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
**The difference is name2@@nodename will also be used to resolve references to name2 by the linker**
https://sourceware.org/binutils/docs/as/Symver.html
//
Patch implements that. If we have name@@ver symbol and name is undefined,
name@@ver is used to resolve references to name.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 306813
Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.
This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.
Patch by Mark Kettenis.
Differential Revision: https://reviews.llvm.org/D34618
llvm-svn: 306565
This is PR33596. Previously LLD would crash
because BYTE command synthesized output section,
but it was not assigned to Sec member of OutputSectionCommand.
Behaviour of -script and -r combination is not well defined,
but it seems after this change LLD naturally inherits behavior of
GNU linkers - creates output section requested in script and does not
crash anymore.
Differential revision: https://reviews.llvm.org/D34676
llvm-svn: 306527
This fixes PR33598.
Size field for undefined symbols is not significant.
Setting it to fixed value, like zero, may be useful though.
For example when we have 2 DSO's, like in this PR, if lower level DSO may
change slightly (in part of some symbol's st_size) and higher-level DSO is
rebuilt, then tools that monitoring checksum of high level DSO file can notice
it and trigger cascade of some other unnecessary actions.
If we set st_size to zero, that can be avoided.
Differential revision: https://reviews.llvm.org/D34673
llvm-svn: 306526
When -ffunction-sections and ARM C++ exceptions are used each .text.suffix
section will have at least one .ARM.exidx.suffix section and may have an
additional .ARM.extab.suffix section if the unwinding instructions are too
large to inline into the .ARM.exidx table entry. For a large program without
a linker script this can lead to a large number of section header table
entries that can increase the size of the ELF file.
This change introduces a default rule for .ARM.extab.* to be placed in
a single output section called .ARM.extab . This follows the behavior of
ld.gold and ld.bfd.
fixes pr33407
Differential Revision: https://reviews.llvm.org/D34678
llvm-svn: 306522
It is somewhat pointless to check that a specific error is not
produced. That is already checked by the ld.lld exit value.
Instead make the test a bit stronger by checking that the output file
has the expected symbol and section.
llvm-svn: 306496
This patch fills holes in executable sections with 0xd4 (ARM) or
0xef (MIPS). These trap instructions were suggested by Theo de Raadt.
llvm-svn: 306322
On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..
If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.
Differential Revision: https://reviews.llvm.org/D34355
llvm-svn: 306282
This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.
One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.
Differential Revision: https://reviews.llvm.org/D34547
llvm-svn: 306126
Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.
This pathc saves the original symbol name and restore it after memcpy
to keep the original name.
This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.
llvm-svn: 306036
The --exclude-libs option is not a popular option, but at least some
programs in Android depend on it, so it's worth to support it.
Differential Revision: https://reviews.llvm.org/D34422
llvm-svn: 305920
I found this while trying to build u-boot. It uses -Ttext in
combination with linker scripts.
My first reaction was to change the linker scripts to have the correct
value, but I found that it is actually quite convenient to have -Ttext
take precedence.
By having just
.text : { *(.text) }
In the script, they can define the text address in a single Makefile
and pass it to ld with -Ttext and for the C code with
-DFoo=value. Doing the same with linker scripts would require them to
be generated during the build.
llvm-svn: 305766
This patch adds support for segment NONE in linker scripts which enables the
specification that a section should not be assigned to any segment.
Note that GNU ld does not disallow the definition of a segment named NONE, which
if defined, effectively overrides the behaviour described above. This feature
has been copied.
Differential Revision: https://reviews.llvm.org/D34203
llvm-svn: 305700
In r305364, Rui changed the mechanism that parses -z option values slightly.
This caused a bug, as demonstrated by this test, which now fails:
---
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t -z max-page-size
.global _start
_start:
nop
---
Before, the link succeeded and set the max-page-size to the target default.
After we get the following two error messages:
"invalid max-page-size: "
"max-page-size: value isn't a power of 2"
The latter error is because an uninitialised variable ends up being passed back
to getMaxPageSize).
This change ensures we only get the first error.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D34234
llvm-svn: 305679
This is necessary to ensure that sections containing symbols referenced
from linker scripts (e.g. in data commands) don't get GC'd.
Differential Revision: https://reviews.llvm.org/D34195
llvm-svn: 305452
Currently we do layout as if non alloc sections had an actual address
and then set it to zero. This produces a few odd results where a
symbol has an address that is inconsistent with the section address.
The simplest way to fix it is probably to just set the address earlier.
The behavior of bfd seems to be similar, but it only sets the non
alloc section address is missing from the linker script or if the
script has an explicit " : 0" setting the address of the output
section (which the default script does).
llvm-svn: 305323
This shows an oddity of this output. While the section address is 0,
the the symbol address is computed as if the section was allocatable.
llvm-svn: 305250
The ELF standard defines that the SHT_GROUP section as follows:
- its sh_link has the symbol index, and
- the symbol name is used to uniquify section groups.
Object files created by GNU gold does not seem to comply with the
standard. They have this additional rule:
- if the symbol has no name and a STT_SECTION symbol, a section
name is used instead of a symbol name.
If we don't do anything for this, the linker fails with a mysterious
error message if input files are generated by gas. It is unfortunate
but I think we need to support it.
Differential Revision: https://reviews.llvm.org/D34064
llvm-svn: 305218
Given
.weak target
.global _start
_start:
b target
The intention is that the branch goes to the instruction after the
branch, effectively turning it on a nop. The branch adds the runtime
PC, but we were adding it statically too.
I noticed the oddity by inspection, but llvm-objdump seems to agree,
since it now prints things like:
b #-4 <_start+0x4>
llvm-svn: 305212
Relocations referring to merge sections are considered equal if they
resolve to the same offset in the same output section.
Differential Revision: https://reviews.llvm.org/D34094
llvm-svn: 305177
Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).
If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.
What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).
Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too. An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070
This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.
bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html
llvm-svn: 305135
SHF_GROUP bit doesn't make sense in executables or DSOs, so linkers are
expected to remove that bit from section flags. We did that when we create
output sections.
This patch is to do that earlier than before. Now the flag is dropped when
we instantiate input section objects.
This change improves ICF. Previously, two sections that differ only in
SHF_GROUP flag were not merged, because when the control reached ICF,
the flag was still there. Now the flag is dropped before reaching to ICF,
so the difference is ignored naturally.
This issue was found by pcc.
Differential Revision: https://reviews.llvm.org/D34074
llvm-svn: 305134
This is used by linux kernel build system.
(https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt "3.2 Built-in object goals")
It has for example next configuration for linking built-in.o files:
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
drivers-$(CONFIG_PCI) += arch/ia64/pci/
...
drivers-$(CONFIG_OPROFILE) += arch/ia64/oprofile/
Im most simple case all CONFIG_* options are off. That means linker is called with empty input archive,
emulation option and no inputs and expected to generate some relocatable output.
ld.bfd is able to do that, we dont.
Patch allows to support this case.
Differential revision: https://reviews.llvm.org/D33937
llvm-svn: 305069
The symbols generated for Thunks have type STT_FUNC, to permit a thunk to
be reused via a blx instruction the Thumb bit (0) needs to be set properly.
Differential Revision: https://reviews.llvm.org/D34036
llvm-svn: 305065
Previously, it couldn't parse
SECTIONS .text (0x1000) : { *(.text) }
because "(" was interpreted as the begining of the "(NOLOAD)" directive.
llvm-svn: 305006
Thunks are now generated per InputSectionDescription instead of per
OutputSection. This allows created ThunkSections to be inserted directly
into InputSectionDescription.
Changes in this patch:
- Loop over InputSectionDescriptions to find relocations to Thunks
- Generate a ThunkSection per InputSectionDescription
- Remove synchronize() as we no longer need it
- Move fabricateDefaultCommands() before createThunks
Differential Revision: https://reviews.llvm.org/D33835
llvm-svn: 304887
Previously we would merge relocation sections by name.
That did not work in some cases, like testcase shows.
Patch implements logic to merge relocation sections if their target
sections were merged into the same output section.
Differential revision: https://reviews.llvm.org/D33824
llvm-svn: 304886
When linking linux kernel LLD currently reports next errors:
ld: error: unable to evaluate expression: input section .head.text has no output section assigned
ld: error: At least one side of the expression must be absolute
ld: error: At least one side of the expression must be absolute
That does not provide file/line information and overall looks unclear.
Patch adds location information to ExprValue and that allows
to provide more clear error messages.
Differential revision: https://reviews.llvm.org/D33943
llvm-svn: 304881
Previously LLD would fail for case when there are multiple comdats and -r.
That happened because it merged all ".group" (SHT_GROUP) sections into single
output, producing broken result. Such sections may have similar name, alignment and flags
and other properties. We need to produce separate output section for each such input one.
Differential revision: https://reviews.llvm.org/D33643
llvm-svn: 304769
Traditionally, it has been defined in crtbegin.o, which is typically
provided by libgcc or as part of the C library on some systems. However,
but there's no principled reason for it to be there. We optionaly
define this symbol, which can be used on platforms that don't provide
__dso_handle in crtbegin.o or which don't use crtbegin.o at all.
Differential Revision: https://reviews.llvm.org/D33856
llvm-svn: 304732
procedural optimizations to prevent dropping symbols and allow the linker
to process re-directs.
PR33145: --wrap doesn't work with lto.
Differential Revision: https://reviews.llvm.org/D33621
llvm-svn: 304719
This is PR33289.
Previously LLD leaved section naming as is and that lead to wrong result,
because we decompress sections when using -r,
and hence should remove ".z" prefix.
Differential revision: https://reviews.llvm.org/D33885
llvm-svn: 304711
Spec says: (http://www.sco.com/developers/gabi/latest/ch4.sheader.html)
sh_info
This member holds extra information, whose interpretation depends on the section type.
If the sh_flags field for this section header includes the attribute SHF_INFO_LINK,
then this member represents a section header table index.
SHF_INFO_LINK
The sh_info field of this section header holds a section header table index.
Since sh_info for SHT_REL[A] sections should contain the section header index of the
section to which the relocation applies, this is
consistent with spec to put this flag. Behavior matches both bfd and gold as well.
Differential revision: https://reviews.llvm.org/D33763
llvm-svn: 304531
George Rimar