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
Without this, when building with shared BUILD_SHARED_LIBS=ON
I get errors such as:
lib/Core/Reader.cpp:40: error: undefined reference to
'llvm::identify_magic(llvm::StringRef)'
Differential Revision: https://reviews.llvm.org/D34004
llvm-svn: 304932
This patch reimplements .gdb_index in more natural way,
that makes proccess of switching to multithreaded index building to
be trivial.
Differential revision: https://reviews.llvm.org/D33552
llvm-svn: 304927
Approach significantly simplifies LLD .gdb_index code and makes it much faster.
Also it should resolve issues, like D33176 tries to address once and forever in a clean way.
LLC binary linking without patch and without --gdb-index: 1,599241063
LLC binary linking without patch and with --gdb-index: 6,064316262
LLC binary linking with patch and with --gdb-index: 4,116792104
Time spent for building gdbindex changes from (6,064316262 - 1,599241063 == 4,465075199)
to (4,116792104- 1,599241063 == 2,517551041).
That is 2,517551041/4,465075199 = 0,564 or about 44% speedup.
Differential revision: https://reviews.llvm.org/D33183
llvm-svn: 304895
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
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
Before this patch in -r we compute the OutputSection sizes early in
the various calls to assignOffsets. With this change we can remove
most of those calls.
llvm-svn: 304860
In preparation for inserting Thunks into InputSectionDescription::Sections
extract the loop that finds InputSections that may have calls that need
Thunks. This isn't much benefit now but this will be useful when we have to
extract the InputSectionDescriptions::Sections from the script.
Differential Revision: https://reviews.llvm.org/D33834
llvm-svn: 304783
In preparation for inserting Thunks into InputSectionDescriptions this
simple change associates added Thunks with a vector of InputSections instead
of an OutputSection. As of now we are just using OutputSection::Sections.
Differential Revision: https://reviews.llvm.org/D33832
llvm-svn: 304782
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
This change alters the sorting for OutputSections with the SHF_LINK_ORDER
flag in OutputSection::finalize() to use the InputSectionDescription
representation and not the OutputSection::Sections representation.
Differential revision: https://reviews.llvm.org/D33772
llvm-svn: 304700
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
This is probably the correct location for it: next to
fabricateDefaultCommands. If we don't have a linker script, we
fabricate one. If we have one, we patch it.
llvm-svn: 304436
This is PR33243. R_GOTONLY_PC_FROM_END was not in a list of link time constant
expressions and that was a result of confusiing messages like PR shows:
/usr/bin/ld.lld: error: /usr/lib/go/src/runtime/alg.go:47:
can't create dynamic relocation R_386_GOTPC against local symbol in readonly segment defined in /tmp/nice/go-link-597453838/go.o
Though in reality we just should not have try to create a dynamic relocation for this case at all.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D33717
llvm-svn: 304393
We were looking up sections by name during expression evaluation. By
keeping track of forward declarations we can do the lookup during
script parsing.
Doing the lookup earlier will be more efficient when assignAddresses
is run twice and removes two uses of OutputSections.
llvm-svn: 304381
Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.
This was brittle and caused bugs like the one fixed by r304260.
We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.
llvm-svn: 304338
We would crash if a SHF_LINK_ORDER section pointed to a non
InputSection section. Since those sections are not merged in order,
SHF_LINK_ORDER is pretty meaningless and we can error on that case.
llvm-svn: 304327
This change converts the writing of the .ARM.exidx sentinel section to use
the InputSectionDescriptions instead of OutputSection::Sections this is in
preparation for the retirement of OutputSection::Sections.
Differential Revision: https://reviews.llvm.org/D33500
llvm-svn: 304289
This happens when attempting to link shared libraries using exceptions on
MIPS. It requires -z notext because clang generates R_MIPS_64 relocations
inside .eh_frame.
The crash happened because for EhInputSection the OutSec member is null.
Patch by Alexander Richardson!
llvm-svn: 304260
When there is a linker script with .ARM.exidx in the SECTIONS
command we must add the .ARM.exidx sentinel section to the
InputSectionDescriptions as well as to OutputSection::Sections.
Differential Revision: https://reviews.llvm.org/D33496
llvm-svn: 304206
I found that during visual inspection of code while wrote different patch.
Script in testcase probably have nothing common with real life, but
we segfault currently using it.
If output section is known NOBITS, there is no need to create
writers threads for doing nothing or proccess any filler logic that
is useless here. We can just early return, that is what this patch do.
DIfferential revision: https://reviews.llvm.org/D33646
llvm-svn: 304192
InputSections may contain MergeInputSection members which trigger
a segmentation fault when trying to cast them to InputSection.
Differential Revision: https://reviews.llvm.org/D33628
llvm-svn: 304189
While the following expression is handled fine:
PROVIDE_HIDDEN(newsym = oldsym + address);
The following expression triggers an error because the expression
is evaluated as absolute:
PROVIDE_HIDDEN(newsym = ALIGN(oldsym, CONSTANT(MAXPAGESIZE)) + address);
To avoid this error, we use late evaluation for ALIGN by making the
alignment an attribute of the expression itself.
Differential Revision: https://reviews.llvm.org/D33629
llvm-svn: 304185
Now that we are trying to use the linker script representation as the
canonycal one, there are a few loops looking for just OutputSectionCommands.
Create a vector with just the OutputSectionCommands once that is
stable to simplify the rest of the code.
llvm-svn: 304181
This is PR33052, "Bug 33052 - -r eats comdats ".
To fix it I stop removing group section from out when -r is given
and fixing SHT_GROUP content when writing it just like we do some
other fixup, e.g. for Rel[a]. (it needs fix for section indices that
are in group).
Differential revision: https://reviews.llvm.org/D33485
llvm-svn: 304140
The .dynamic section of an ELF almost doesn't need to be written to with
the exception of the DT_DEBUG entry. For several reasons having a read
only .dynamic section would be useful. This change adds the -z keyword
"rodynamic" which forces .dynamic to be read-only. In this case DT_DEBUG
will not be emited.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D33251
llvm-svn: 304024
On SPARC, .plt is both writeable and executable. The current way
sections are sorted means that lld puts it after .data/.bss. but it
really needs to be close to .test to make sure branches into .plt
don't overflow. I'd argue that because .bss is supposed to come last
on all architectures, we should change the default sort order such
that writable and executable sections come before sections that are
just writeable. read-only executable sections should still come after
sections that are just read-only of course. This diff makes this
change.
llvm-svn: 304008
I found this when builded llc binary using gcc 5.4.1 + LLD.
gcc produces duplicate entries in .debug_gnu_pubtypes section, ex:
UnifyFunctionExitNodes.cpp.o has:
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"
0x0000ac07 EXTERNAL TYPE "std::success_type<void*>"
clang produces single entry here:
0x0000d291 EXTERNAL TYPE "std::__success_type<void *>"
If we link output from gcc with LLD, that would produce excessive duplicate
entries in .gdb_index constant pool area. That does not seem affect gdb work,
but makes .gdb_index larger than it can be.
I also checked that gold filters out such duplicates too. Patch fixes it.
Differential revision: https://reviews.llvm.org/D32647
llvm-svn: 303975
https://sourceware.org/gdb/onlinedocs/gdb/Index-Section-Format.html says:
"A CU vector in the constant pool is a sequence of offset_type values.
The first value is the number of CU indices in the vector.
Each subsequent value is the index and symbol attributes of a CU in the CU list."
Previously we keeped 2 values until the end, what was useless.
Initially was a part of D32647, though it is possible to split out.
Patch do that.
Differential revision: https://reviews.llvm.org/D33551
llvm-svn: 303973
In this way, the content and the flag is always consistent, which I
think better than removing the bit when input sections reaches the Writer.
llvm-svn: 303926
It is not clear why a synthetic section wants to use padding defined
in the linker script. The padding is for the space between sections.
It was also missing a test.
llvm-svn: 303812
This is the only place we use threads for ICF. The intention of this code
was to split an input vector into 256 shards and process them in parallel.
What the code was actually doing was to split an input into 257 shards,
process the first 256 shards in parallel, and the remaining one in serial.
That means this code takes ceil(256/n)+1 instead of ceil(256/n) where n
is the number of available CPU cores. The former converges to 2 while
the latter converges to 1.
This patches fixes the above issue.
llvm-svn: 303797
Summary:
This is required on some platforms, as GNU libstdc++ std::call_once is known to be buggy.
This fixes operation of LLD on at least NetBSD and perhaps OpenBSD and Linux PowerPC.
The same change has been introduced to LLVM and LLDB.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, #lld
Tags: #lld
Differential Revision: https://reviews.llvm.org/D33508
llvm-svn: 303788
A variable `ComdatGroup` is not supposed to contain a large number of
items. Even when linking clang, it ends up having only 300K strings.
It doesn't make sense to use CachedHashStringRef for this hash table.
This patch has neutral or slightly positive impact on performance while
reducing code complexity.
llvm-svn: 303787
This reduces how many times we have to map from OutputSection to
OutputSectionCommand. It is a required step to moving
clearOutputSections earlier.
In order to always use writeTo in OutputSectionCommand we have to call
fabricateDefaultCommands for -r links and move section compression
after it.
llvm-svn: 303784
Once the dummy linker script is created, we want it to be used for
everything to avoid having two redundant representations that can get
out of sync.
We were already clearing OutputSections. With this patch we clear the
Sections vector of every OutputSection.
llvm-svn: 303703
By the time we get to linker scripts, all special InputSectionBase
should have been combined into synthetic sections, which are a type of
InputSection. The net result is that we can use InputSection in a few
places that were using InputSectionBase.
llvm-svn: 303702
If the compiler driver passes --build-id and the user uses -Wl to
pass --build-id= then the user's flag should take precedence.
Differential Revision: https://reviews.llvm.org/D33461
llvm-svn: 303689
Peter Collingbourne