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
The .def file parser changes I reverted broke this test case, and
exported "__imp__foo" instead of "__imp__foo@8". This was
http://crbug.com/728726.
llvm-svn: 304572
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 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 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 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
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
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
If you pass /delayload:<dllname> to the COFF linker, it creates thunks
so that DLLs are loaded when they are used for the first time instead of
load-time.
This mechanism do not work for data symbols as there's no way to trap
acccesses to data imported from DLLs. (Technically, I think if we do not
initially map dllimport tables in memory, we could actually trap accesses
and delay-load data symbols, but that's not what Windows do.)
This patch is to report an error when you try to delay-load data symbols.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33106
Differential Revision: https://reviews.llvm.org/D33557
llvm-svn: 303890
This is a different implementation than r303225 (which was reverted
in r303270, re-submitted in r303304 and then re-reverted in r303527).
In the previous patch, I tried to add Live bit to each dllimported
symbol. It turned out that it didn't work with "oldnames.lib" which
contains a lot of weak aliases to dllimported symbols.
The way we handle weak aliases is to check if undefined symbols
can be resolved using weak aliases, and if so, memcpy the Defined
symbols to weak Undefined symbols, so that any references to weak
aliases automatically see defined symbols instead of undefined ones.
This memcpy happens before MarkLive kicks in.
That means we may have multiple copies of dllimported symbols. So
turning on one instance's Live bit is not enough.
This patch moves the Live bit to dllimport file. Since multiple
copies of dllsymbols still point to the same file, we can use it as the
central repository to keep track of liveness.
Differential Revision: https://reviews.llvm.org/D33520
llvm-svn: 303814
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
This reverts commit r303304 because it looks like the change
introduced a crash bug. At least after that change, LLD with thinlto
crashes when linking Chromium.
llvm-svn: 303527
Our output is not compatible with the Binding feature, so make it
explicit that.
Differential Revision: https://reviews.llvm.org/D33336
llvm-svn: 303378
Previously, LLD-produced executables had IAT (Import Address Table) and
ILT (Import Lookup Table) as separate chunks of data, although their
contents are identical. My interpretation of the COFF spec when I wrote
the COFF linker is that they need to be separate tables even though they
are the same.
But Peter found that the Windows loader is fine with executables in
which IAT and ILT are merged. This is a patch to merge IAT and ILT.
I confirmed that an lld-link self-hosted with this patch works fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33064
Differential Revision: https://reviews.llvm.org/D33326
llvm-svn: 303374
When /DEBUG is not specified, /PDB should be ignored. When
/DEBUG is specified, a PDB should be output regardless of
whether or not /PDB is specified. /PDB just overrides the
default name.
This patch implements this behavior, and adds some tests, while
also removing a dead option /DEBUGPDB which was unused in any
code.
Differential Revision: https://reviews.llvm.org/D33302
llvm-svn: 303352
This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.
The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.
The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.
Fixes PR32924
Differential Revision: https://reviews.llvm.org/D33280
llvm-svn: 303337
This reverts re-submits r303225 which was reverted in r303270 because it
broke the sanitizer-windows bot.
The reason of the failure is that we were writing dead symbols to the
symbol table. I fixed the issue.
llvm-svn: 303304
and follow-up r303226 "Fix Windows buildbots."
This broke the sanitizer-windows buildbot.
> Previously, the garbage collector (enabled by default or by explicitly
> passing /opt:ref) did not kill dllimported symbols. As a result,
> dllimported symbols could be added to resulting executables' dllimport
> list even if no one was actually using them.
>
> This patch implements dllexported symbol garbage collection. Just like
> COMDAT sections, dllimported symbols now have Live bits to manage their
> liveness, and MarkLive marks reachable dllimported symbols.
>
> Fixes https://bugs.llvm.org/show_bug.cgi?id=32950
>
> Reviewers: pcc
>
> Subscribers: llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D33264
llvm-svn: 303270
Summary:
Previously, the garbage collector (enabled by default or by explicitly
passing /opt:ref) did not kill dllimported symbols. As a result,
dllimported symbols could be added to resulting executables' dllimport
list even if no one was actually using them.
This patch implements dllexported symbol garbage collection. Just like
COMDAT sections, dllimported symbols now have Live bits to manage their
liveness, and MarkLive marks reachable dllimported symbols.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32950
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33264
llvm-svn: 303225
We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.
This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.
A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.
Differential Revision: https://reviews.llvm.org/D33176
llvm-svn: 303089
We used to place orphans by just using compareSectionsNonScript.
Then we noticed that since linker scripts can use another order, we
should first try match the section to a given PT_LOAD. But there is
nothing special about PT_LOAD. The same issue can show up for
PT_GNU_RELRO for example.
In general, we have to search for the most similar section and put the
orphan next to it. Most similar being defined as how long they follow
the same code path in compareSecitonsNonScript.
That is what this patch does. We now compute a rank for each output
section, with a bit for each branch in what was
compareSectionsNonScript.
With this findOrphanPos is now fully general and orphan placement can
be optimized by placing every section with the same rank at once.
The included testcase is a variation of many-sections.s that uses
allocatable sections to avoid the fast path in the existing
code. Without threads it goes form 46 seconds to 0.9 seconds.
llvm-svn: 302903
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
Both gold and bfd restrict that one:
ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var
What looks reasonable because it is 32 bit one. Patch do the same.
Differential revision: https://reviews.llvm.org/D33100
llvm-svn: 302881
Previously we were not printing out the type of the incompatible section
which made it difficult to determine what the problem was.
The error message format has been change to the following:
error: section type mismatch for .shstrtab
>>> <internal>:(.shstrtab): SHT_STRTAB
>>> output section .shstrtab: Unknown
Patch by Alexander Richardson.
Differential Revision: https://reviews.llvm.org/D32488
llvm-svn: 302694
This behavior differs from the semantics implemented by GNU linkers
which only define this symbol iff ELF headers are in the memory
mapped segment.
Differential Revision: https://reviews.llvm.org/D33019
llvm-svn: 302687
This is PR32664.
Issue was revealed by linux kernel script which was:
SECTIONS {
. = (0xffffffff80000000 + ALIGN(0x1000000, 0x200000));
phys_startup_64 = ABSOLUTE(startup_64 - 0xffffffff80000000);
.text : AT(ADDR(.text) - 0xffffffff80000000) {
.....
*(.head.text)
Where startup_64 is in .head.text.
At the place of assignment to phys_startup_64 we can not calculate absolute value for startup_64
because .text section has no VA assigned. Two patches were prepared earlier to address this: D32173 and D32174.
And in comments for D32173 was suggested not try to support this case, but error out.
Differential revision: https://reviews.llvm.org/D32793
llvm-svn: 302668
Adds support for the ORIGIN and LENGTH linker script built in functions.
ORIGIN(memory) Return the origin of the memory region
LENGTH(memory) Return the length of the memory region
Redo of D29775 for refactored linker script parsing.
Patch by Robert Clarke
Differential Revision: https://reviews.llvm.org/D32934
llvm-svn: 302564
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
Previously it was impossible to use linkerscript with --compress-debug-sections
because of assert failture:
Assertion failed: isFinalized(), file C:\llvm\lib\MC\StringTableBuilder.cpp, line 64
Patch fixes the issue
llvm-svn: 302413
The test ELF/lto/thin-archivecollision.ll was not testing what it
wanted to test. It needs two archive members with the same name, but
different offsets.
Without this we could remove all references of OffsetInArchive and all
tests would still pass.
Fixing the test showed that the --whole-archive case was broken, which
this patch fixes.
llvm-svn: 302241
We were correctly computing the size contribution of a .tbss input
section (it is none), but we were incorrectly considering the
alignment of the output section: it was advancing Dot instead of
ThreadBssOffset.
As far as I can tell this was always wrong in our linkerscript
implementation, but that became more visible now that the code is
shared with the non linker script case.
llvm-svn: 302107
It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.
Differential Revision: https://reviews.llvm.org/D32721
llvm-svn: 302083
The --section-start <name>=<address> needs to be translated into equivalent
linker script commands. There are a couple of problems with the existing
implementation:
- The --section-start with the lowest address is assumed to be at the start
of the map. This assumption is incorrect, we have to iterate through the
SectionStartMap to find the lowest address.
- The addresses in --section-start were being over-aligned when the
sections were marked as PageAlign. This is inconsistent with the use of
SectionStartMap in fixHeaders(), and can cause problems when the PageAlign
causes an "unable to move location counter backward" error when the
--section-start with PageAlign is aligned to an address higher than the next
--section-start. The ld.bfd and ld.gold seem to be more consistent with this
approach but this is not a well specified area.
This change fixes the problems above and also corrects a typo in which
fabricateDefaultCommands() is called with the wrong parameter, it should be
called with AllocateHeader not Config->MaxPageSize.
Differential Revision: https://reviews.llvm.org/D32749
llvm-svn: 302007
Before rL301170 was landed, LLD did not produce correct entries in .gdb_index address area.
Issue was fixed on LLVM DWARF parsers side and was relative to how .debug_ranges
section was scanned. It was main problem of PR32319.
It makes sense to have testcase on LLD size too. This checks that we generate proper values
now, because we do not have any tests for .gdb_index which works with .debug_ranges atm.
Differential revision: https://reviews.llvm.org/D32750
llvm-svn: 302006
Strip on OpenBSD does not correctly handle an empty .eh_frame section
and produces broken binaries in that case. Currently lld creates such
an empty .eh_frame section, despite the fact that the OpenBSD crtend.o
explicitly inserts a terminator. The Linux LSB "standard":
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME
explicitly says that
The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records.
This diff includes a test that specifically tests the issue I'm seeing
on OpenBSD.
Patch by Mark Kettenis!
llvm-svn: 301931
When using linkerscripts we were trying to sort SHF_LINK_ORDER
sections too early. Instead of always doing two runs of
assignAddresses, record the section order in processCommands.
llvm-svn: 301830
This patch is to ignore .debug_gnu_pub{names,types} sections if the
-gdb-index option was given.
Differential Revision: https://reviews.llvm.org/D32662
llvm-svn: 301710
Previously, we printed out input sections and input files in
separate columns as shown below.
Address Size Align Out In File Symbol
0000000000201000 0000000000000015 4 .text
0000000000201000 000000000000000e 4 .text
0000000000201000 000000000000000e 4 foo.o
0000000000201000 0000000000000000 0 _start
0000000000201005 0000000000000000 0 f(int)
000000000020100e 0000000000000000 0 local
0000000000201010 0000000000000002 4 bar.o
0000000000201010 0000000000000000 0 foo
0000000000201011 0000000000000000 0 bar
This format doesn't make much sense because for each input section,
there's always exactly one input file. This patch changes the format
to this.
Address Size Align Out In Symbol
0000000000201000 0000000000000015 4 .text
0000000000201000 000000000000000e 4 foo.o:(.text)
0000000000201000 0000000000000000 0 _start
0000000000201005 0000000000000000 0 f(int)
000000000020100e 0000000000000000 0 local
0000000000201010 0000000000000002 4 bar.o:(.text)
0000000000201010 0000000000000000 0 foo
0000000000201011 0000000000000000 0 bar
Differential Revision: https://reviews.llvm.org/D32657
llvm-svn: 301683
We found that some part of code for the -Map option takes O(m*n)
where m is the number of input sections in some file and n is
the number of symbols in the same file. If you do LTO, we usually
have only a few object files as inputs for the -Map option
feature, so this performance characteristic was worse than I
expected.
This patch rewrites the -Map option feature to speed it up.
I eliminated the O(m*n) bottleneck and also used multi-threading.
As a result, clang link time with the -Map option improved from
18.7 seconds to 11.2 seconds. Without -Map, it takes 7.7 seconds,
so the -Map option is now about 3x faster than before for this
test case (from 11.0 seconds to 3.5 seconds.) The generated output
file size was 223 MiB, and the file contains 1.2M lines.
Differential Revision: https://reviews.llvm.org/D32631
llvm-svn: 301659
CONSTANT imports expect both the `_imp_` prefixed and non-prefixed
symbols should be added to the symbol table. This allows for linking
symbols like _NSConcreteGlobalBlock in WinObjC. The previous change
would generate the import library properly by handling the option but
would not consume the generated entry properly.
llvm-svn: 301657
This seems to be the behavior of the MSVC linker. Previously, this
incompatibility caused nasty issues in chromium build a few times.
Differential Revision: https://reviews.llvm.org/D30363
llvm-svn: 301598
We were already pretty close, the one exception was when a name was
reused in another SECTIONS directive:
SECTIONS {
.text : { *(.text) }
.data : { *(.data) }
}
SECTIONS {
.data : { *(other) }
}
In this case we would create a single .data and magically output
"other" while looking at the first OutputSectionCommand.
We now create two .data sections. This matches what gold does. If we
really want to create a single one, we should change the parser so that
the above is parsed as if the user had written
SECTIONS {
.text : { *(.text) }
.data : { *(.data) *(other)}
}
That is, there should be only one OutputSectionCommand for .data and
it would have two InputSectionDescriptions.
By itself this patch makes the code a bit more complicated, but is an
important step in allowing assignAddresses to operate just on the
linker script.
llvm-svn: 301484
Marking them as used causes them to be considered visible outside of LTO. This
prevents the symbols from being internalized or discarded, either by GlobalDCE
or by summary-based dead stripping in ThinLTO.
This change makes it unnecessary to add these symbols to llvm.compiler.used
in the backend, as the symbols are kept alive by virtue of being external,
so remove the backend code that handles that.
Fixes PR32798.
Differential Revision: https://reviews.llvm.org/D32544
llvm-svn: 301438
gnu ld description of option is:
--defsym=symbol=expression
Create a global symbol in the output file, containing the absolute address given
by expression. You may use this option as many times as necessary to define multiple
symbols in the command line. A limited form of arithmetic is supported for the
expression in this context: you may give a hexadecimal constant or the name of an
existing symbol, or use "+" and "-" to add or subtract hexadecimal constants or
symbols. If you need more elaborate expressions, consider using the linker command
language from a script. Note: there should be no white space between symbol,
the equals sign ("="), and expression.
In compare with D32082, this patch does not support math expressions and absolute
symbols. It implemented via code similar to --wrap. That covers 1 of 3 possible
--defsym cases.
Differential revision: https://reviews.llvm.org/D32171
llvm-svn: 301391
Looks like `echo "{_start;};"` on lld-x86_64-win7 bot echoes `_start;;`
for some reason. I cannot reproduce the issue locally. I suspect that
it might be interpreting {<word>} in a special way. This patch is to
attempt to fix it by appending space characters.
llvm-svn: 301353
Previously we were not printing out the flags of the incompatible
section which made it difficult to determine what the problem was.
The error message format has been change to the following:
error: incompatible section flags for .bar
>>> /foo/bar/incompatible-section-flags.s.tmp.o:(.bar): 0x403
>>> output section .bar: 0x3
Patch by Alexander Richardson.
Differential Revision: https://reviews.llvm.org/D32484
llvm-svn: 301319
BSD's __progname symbol is defined in crt1.o and linked against main
executables. The libc expects that main executables export __progname
symbol via .dynsym sections. In order to handle this case, we scan
undefined symbols in DSOs and exported them by setting Sym->ExportDynamic
to true.
But it turned out that setting that variable is not enough to make sure
that symbols are exported in all use cases. If a -dynamic-list option is
given, all symbols not explicitly mentioned in a version script are
hidden by default. That hides __progname symbol. This patch fixes the issue.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32703
llvm-svn: 301282
This relocation type has an implicit addend. Account for it when
processing the relocation. Add an offset to an existing test to ensure
it gets processed correctly.
Fixes PR32634.
Differential Revision: https://reviews.llvm.org/D32336
llvm-svn: 301207
Summary: When using /msvclto, lld and MSVC's linker both do their own symbol resolution. This can cause them to select different archive members, which can result in undefined references. This change avoids that situation by extracting archive members that are selected by lld and passing those to link.exe before any archives, so that MSVC's uses those objects for symbol resolution instead of different archive members.
Reviewers: pcc, rnk, ruiu
Reviewed By: pcc
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D32317
llvm-svn: 301045
The CONSTANT export type is marked as obsolete, but link still supports
this. Furthermore, WinObjC uses this for certain exports. Add support
for this export type.
llvm-svn: 301013
This change fabricates linker script commands for the case where there is
no linker script SECTIONS to control address assignment. This permits us
to have a single Script->assignAddresses() function.
There is a small change in user-visible-behavior with respect to the
handling of .tbss SHT_NOBITS, SHF_TLS as the Script->assignAddresses()
requires setDot() to be called with monotically increasing addresses.
The tls-offset.s test has been updated so that the script and non-script
results match.
This change should make the non-script behavior of lld closer to an
equivalent linker script.
Differential Revision: https://reviews.llvm.org/D31888
llvm-svn: 300687
Patch implements --compress-debug-sections=zlib.
In compare with D20211 (a year old patch, abandoned), it implementation
uses streaming and fully reimplemented, does not support zlib-gnu for
simplification.
This is PR32308.
Differential revision: https://reviews.llvm.org/D31941
llvm-svn: 300444
Imagine next script:
SECTIONS { BYTE(0x11); }
Section content written to disk will be 0x11. Previous LLD behavior was to make this
section SHT_NOBITS. What is not correct because section has content.
ld.bfd makes such sections SHT_PROGBITS, this patch do the same.
This fixes PR32537
Differential revision: https://reviews.llvm.org/D32016
llvm-svn: 300317
This fixes an assertion `Align != 0u && "Align can't be 0."'
in llvm::alignTo() when a linker script references a globally
defined variable in an ALIGN() context.
Patch by Alexander Richardson !
Differential revision: https://reviews.llvm.org/D31984
llvm-svn: 300315
ARM Exception Index Table sections .ARM.exidx have an implicit dependency
on code sections via SHF_LINK_ORDER. When code sections are folded by ICF
we must mark the unique .ARM.exidx table that describes it as not live
to prevent an illegal entry in the exception table.
Note that we do not try and follow the relocations from the .ARM.exidx
section to the .ARM.extab sections to mark these as not live. Leaving
these sections is not a correctness problem. In theory these could be
removed via an application of garbage collection.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32614
Differential Revision: https://reviews.llvm.org/D31932
llvm-svn: 300182
Previously, we allowed only integers in this context. Now you can
write expressions there. LLD is now able to handle the following
linker, for example.
MEMORY { rom (rx) : ORIGIN = (1024 * 1024) }
llvm-svn: 300131
We do not check for similarities when handling unknown tokens in
linker scripts, so "ORIGI" and "LENTH" are not good tokens as a test
for unknown tokens, as I was tempted to "fix" them.
llvm-svn: 300130
Filenames are case-insensitive on Windows, so when we dispatch based
on argv0, we need to handle it case-insensitively.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32637.
llvm-svn: 300087
Fixes PR32572.
When
(a) a library has no soname
and (b) library is given on the command line with path (and not through -L/-l flags)
DT_NEEDED entry for such library keeps the path as given.
This behavior is consistent with gold and bfd, and is used in compiler-rt test suite.
This is a second attempt after r300007 got reverted. This time relro-omagic test is
changed in a way to avoid hardcoding the path to the test directory in the objdump'd
binary.
llvm-svn: 300011
Fixes PR32572.
When
(a) a library has no soname
and (b) library is given on the command line with path (and not through -L/-l flags)
DT_NEEDED entry for such library keeps the path as given.
This behavior is consistent with gold and bfd, and is used in compiler-rt test suite.
llvm-svn: 300007
Summary:
This lets PDB readers lookup type record data by type index in O(log n)
time. It also enables makes `cvdump -t` work on PDBs produced by LLD.
cvdump will not dump a PDB that doesn't have an index-to-offset table.
The table is sorted by type index, and has an entry every 8KB. Looking
up a type record by index is a binary search of this table, followed by
a scan of at most 8KB.
Reviewers: ruiu, zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31636
llvm-svn: 299958
Previously we silently produced broken output for R_386_GOT32X/R_386_GOT32
relocations if they were used to compute the address of the symbol’s global
offset table entry without base register when position-independent code is disabled.
Situation happened because of recent ABI changes. Released ABI mentions that
R_386_GOT32X can be calculated in a two different ways (so we did not follow ABI here
before this patch), but draft ABI also mentions R_386_GOT32 relocation here.
We should use the same calculations for both relocations.
Problem is that we always calculated them as G + A - GOT (offset from end of GOT),
but for case when PIC is disabled, according to i386 ABI calculation should be G + A,
what should produce just an address in GOT finally.
ABI: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-draft.pdf (p36, p60).
llvm-svn: 299812
When the target of the TlsOffsetRel is non-preemptible we can write the
offset directly into the GOT without needing a dynamic relocation. This
is optional for dynamically linked executables but is required for static
linking.
This change adds the relocation to the GOT entry and a test case for
non-0 offsets so that if we miss out the offset the test won't spuriously
pass by virtue of the default value being 0.
Differential Revision: https://reviews.llvm.org/D31749
llvm-svn: 299751
The /appcontainer flag indicates that the module may only be used inside
an application container (for isolation). This has been supported by
link.exe since Windows 8.0. It sets an additional bit in the PE DLL
Characteristics flag to indicate the behavioural change.
llvm-svn: 299728
Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.
Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D30886
Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635
Previously, the code we set to our .plt entries expected that .got
and .got.plt are consecutive in the virtual address space.
Since %ebx points to the last entry of .got for position-independent
code, it assumed that .got is accessible with small negative
displacements and .got.plt are accessible with small positive
displacements.
That assumption was simply wrong. We don't impose any restrictions on
relative layout of .got and .got.plt. As a result, the control is
transferred to a bogus address from .plt at runtime, which resulted in
segfaults.
This patch removes that wrong assumption. We still assume that .got.plt
has a fixed relative address to .got, but we no longer assume that they
are consecutive in memory.
With this change, a "hello world" program compiled with -fPIC works.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31332.
Differential Revision: https://reviews.llvm.org/D31682
llvm-svn: 299553
GNU linkers define __bss_start symbol.
Patch teaches LLD to do that. This is PR32051.
Below is part of standart ld.bfd script:
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
. = .;
__bss_start = .;
.bss :
{
Currently LLD can emit up to 3 .bss* sections as one of testcase shows.
Implementation inserts this symbol before first .bss* output section.
Differential revision: https://reviews.llvm.org/D30419
llvm-svn: 299528
Summary:
This adds support for reporting multiple errors in a single invocation of lld-link. The limit defaults to 20 and can be changed with the /ERRORLIMIT command line parameter, or set to unlimited by passing a value of 0.
This is a new attempt after r295507, which was reverted because opening files raced with exiting early, causing the test to be flaky. This version avoids the race by exiting before calling enqueuePath.
Reviewers: pcc, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits, dblaikie
Differential Revision: https://reviews.llvm.org/D31688
llvm-svn: 299496
The ELF spec says:
all of the non-default visibility attributes, when applied to a symbol
reference, imply that a definition to satisfy that reference must be
provided within the current executable or shared object.
But we were trying to resolve those undef references to shared
symbols. That causes odd results like creating a got entry with
a relocation pointing to 0.
llvm-svn: 299464
As with the changes made in r297645, we do not want a potentially long link to
be run, if it will ultimately fail because the map file is not writable. This
change reuses the same functionality as the output file path check. See
https://reviews.llvm.org/D30449 for further justification and explanations.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D31603
llvm-svn: 299420
The existing names for the ARM and Thumb Thunks highlight their current
use as interworking Thunks. These Thunks can also be used for range
extension Thunks where there is no state change. This change makes the name
more generic so it is suitable for range extension.
Differential Revision: https://reviews.llvm.org/D31605
llvm-svn: 299418
Previous error message style:
error: /home/alice/src/bar.c:12: relocation R_X86_64_PLT32 cannot refer to absolute symbol 'answer' defined in /home/alice/src/foo.o
New error message style:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: foo
>>> defined in /home/alice/src/foo.o
>>> referenced by bar.c:12 (/home/alice/src/bar.c:12)
>>> /home/alice/src/bar.o:(.text+0x1)
llvm-svn: 299390
This patch is intended to improve readability of "duplicate symbol"
error messages.
Without this patch:
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Relocations.cpp:1054: duplicate symbol 'lld:🧝:demangle(llvm::StringRef)'
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Strings.cpp:93: previous definition was here
With this patch:
/ssd/clang/bin/ld.lld: error: duplicate symbol: lld:🧝:demangle(llvm::StringRef)
>>> defined at Strings.cpp:93 (/ssd/llvm-project/lld/ELF/Strings.cpp:93)
>>> Strings.cpp.o:(lld:🧝:demangle(llvm::StringRef)) in archive lib/liblldELF.a
>>> defined at Relocations.cpp:1054 (/ssd/llvm-project/lld/ELF/Relocations.cpp:1054)
>>> Relocations.cpp.o:(.text+0x4C30) in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31507
llvm-svn: 299280
This is a test change applicable for ARM targets.
Previously LLVM would generate a mapping symbol when code contains only
data. This was changed as part of
https://reviews.llvm.org/D30724
and to be more close to the ARM ELF ABI.
The test case is changed to check for behavior with minimal changes.
Patch by Shankar Easwaran
Differential Revision: https://reviews.llvm.org/D31500
llvm-svn: 299212
Previously, undefined symbol errors are one line like this
and wasn't easy to read.
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld:🧝:InputSectionBase*)'
This patch make it more structured like this.
bin/ld.lld: error: undefined symbol: lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true>
>>> Referenced by Writer.cpp:207 (/ssd/llvm-project/lld/ELF/Writer.cpp:207)
>>> Writer.cpp.o in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31481
llvm-svn: 299097
Summary: In the ELF linker, we create the buffer identifier for bitcode files by appending the object name to the archive name. This change makes the COFF linker do the same. Without the change, ThinLTO builds can fail with an error message about multiple ThinLTO modules per object file, caused by object files contained in different archives having the same name.
Reviewers: pcc, ruiu
Reviewed By: pcc
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D31402
llvm-svn: 298942
.gnu.hash happen to contain only 32-bit integers for 32-bit arch,
but the section contents are not uniform array members, so setting
entsize doesn't make much sense. This behavior seems to have been
blindly copied from GNU linkers.
llvm-svn: 298934
Summary: MSVC does this when producing a PDB.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31316
llvm-svn: 298717
This requires collectign all symbols referenced in the linker script
and adding them to symbol table as undefined symbol.
Differential Revision: https://reviews.llvm.org/D31147
llvm-svn: 298577
This is to improve compatibility with GNU Libtool that expect
/supported targets:.* elf/ in a message for the -help option.
Differential Revision: https://reviews.llvm.org/D31208
llvm-svn: 298568
This will be used in the sanitizer test suite, which wants to use DWARF
line tables.
At some point we should reconsider how LLD handles the long section
names required by DWARF debug sections.
llvm-svn: 298544
Rafael Espindola