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
This patch replaces flush with a last ditch attempt at synchronizing
the section list with the linker script "AST".
The synchronization is a bit of a hack and should in time be avoided
by creating the AST earlier so that modifications can be made directly
to it instead of modifying the section list and synchronizing it back.
This is the main step for fixing
https://bugs.llvm.org/show_bug.cgi?id=32816. With this in place I
think the only missing thing would be to have processCommands assign
section indexes as dummy offsets so that the sort in
OutputSection::finalize works.
With this LinkerScript::assignAddresses becomes much simpler, which
should help with the thunk work.
llvm-svn: 301678
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
This patch is to reduce amount of template uses. The new code is less
exciting and boring than before, but I think it is easier to read.
Differential Revision: https://reviews.llvm.org/D32467
llvm-svn: 301488
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
isFileWritable() checked if a file is writable and then emitted
an error message if it is not writable. So it did more than the
name says. This patch moves error() calls to Driver.
llvm-svn: 301422
This code was not used because of
handleARMTlsRelocation and handleMipsTlsRelocation methods that are called
for these platforms instead of regular TLS code.
Differential revision: https://reviews.llvm.org/D32355
llvm-svn: 301414
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
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
addIgnored defines a given symbol even if there is no existing
symbol with the same name. So, even if libc provides __tls_get_addr,
we should still be able to call addIgnored.
Differential Revision: https://reviews.llvm.org/D32053
llvm-svn: 301290
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
We can just use the existing SoName member variable. It now initially
contains what was in DefaultSoName and is modified if the .so has an
actual soname.
llvm-svn: 301259
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
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
createHeader didn't use data members of Elf_Chdr type and write
directly to a given buffer. That is not a good practice because
the function had a knowledge of the struct layout.
llvm-svn: 300674
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
Start using it in LLD to avoid needing to read bitcode again just to get the
target triple, and in llvm-lto2 to avoid printing symbol table information
that is inappropriate for the target.
Differential Revision: https://reviews.llvm.org/D32038
llvm-svn: 300300
We generally want to use uint64_t instead of uintX_t if the 64-bit
type works for both 32-bit and 64-bit because it is simpler than
the variable-size type.
llvm-svn: 300293
"read" is used as a prefix for functions that read tokens from input
streams. This function doesn't really read anything, but just parses
a given string as an integer, so rename.
llvm-svn: 300281
Replace addModuleReloc with AddTlsReloc so that we can use it for both the
module relocation and the offset relocation.
Differential Revision: https://reviews.llvm.org/D31751
llvm-svn: 300192
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
RELRO is a feature to make segments read-only after dynamic relocations
are applied. It is different from read-only segments because RELRO is
initially writable. And of course RELRO is different from writable
segments.
RELRO is not a very well known feature. We have a series of checks to
make a decision whether a section should be in a RELRO segment or not,
but we didn't describe why. This patch adds comments to explain how
that decision is made.
llvm-svn: 300176
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
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
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
Both functions always use the same GOT sections In<ELFT>::Got and
In<ELFT>::MipsGot respectively, so we do not need to pass them as an
argument.
llvm-svn: 299773
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 handleNoRelaxTlsRelocation handled both ARM and Mips as at a
high-level the actions of what to do when encountering a local dynamic or
global dynamic TLS relocation are the same. However due to Mips using a
custom GOT the differences of the implementation are enough that the
function became difficult to understand.
This change replaces handleNotRelaxTlsRelocation into
handleARMTlsRelocation() and handleMipsTlsRelocation() so that the ARM and
Mips specific code is isolated.
Differential Revision: https://reviews.llvm.org/D31748
llvm-svn: 299750
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
scanRelocs() does a lot of things. It fills InputSection's Relocations vector,
making a decision whether a TLS relocation should be relaxed or not,
and making a decision whether a GOT/PLT slot needs to be created or not.
They don't actually have to be done in a single loop. I want to separate
them so that some of them can be run concurently. As a first step, this
patch moves PLT/GOT slot assignment to beginning of the loop, so that
they just fall through to the next statements. This should make it clear
that that code doesn't affect other parts of the loop.
llvm-svn: 299615
Relocations are abstracted as platform-independent R_TLS_* relocations,
so we don't need to check platform-specific ones to see if a relocation
is TLS GD.
llvm-svn: 299614
Symbols referenced by linker scripts are not necessarily be undefined,
so the previous name didn't convey the meaining of the variable.
llvm-svn: 299573
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
For range extension thunks we will need to repeatedly call createThunks()
until no more thunks are created. We will need to retain the state of
Thunks that we have created so far to avoid recreating them on later
passes. This change does not change the functionality of createThunks().
Differential Revision: https://reviews.llvm.org/D31654
llvm-svn: 299530
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
LinkerScript.cpp contains both the linker script processor and the
linker script parser. I put both into a single file, but the file grown
too large, so it's time to put them into two different files.
llvm-svn: 299515
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
LogName member was added to construct input file names for logging
only once. This patch does this in a different way. Now toString
caches its results.
Differential Revision: https://reviews.llvm.org/D31546
llvm-svn: 299375
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
Introduce symbol table data structures that can be potentially written to
disk, have the LTO library build those data structures using temporarily
constructed modules and redirect the LTO library implementation to go through
those data structures. This allows us to remove the LLVMContext and Modules
owned by InputFile.
With this change I measured a peak memory consumption decrease from 5.4GB to
2.8GB in a no-op incremental ThinLTO link of Chromium on Linux. The impact on
memory consumption is larger in COFF linkers where we are currently forced
to materialize all metadata in order to read linker options. Peak memory
consumption linking a large piece of Chromium for Windows with full LTO and
debug info decreases from >64GB (OOM) to 15GB.
Part of PR27551.
Differential Revision: https://reviews.llvm.org/D31364
llvm-svn: 299168
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
This patch changes GnuHashTableSection implementation
to avoid depend on uintX_t and other ELFT stuff, reducing amount of
changes for following patch(es).
Differential revision: https://reviews.llvm.org/D31184
llvm-svn: 298998
.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
This patch calls getAddend on a relocation only when the relocation is RELA.
That doesn't really improve runtime performance but should improve
readability as the code now matches the function description.
llvm-svn: 298828
Previously, computeAddend had many parameters but most of them were
used only for MIPS. The MIPS ABI is too odd that I don't want to mix
it into the regular code path. Splitting the function into non-MIPS
and MIPS parts makes the regular code path easy to follow.
llvm-svn: 298817
C is short for Chunk, but we are no longer using that term.
RI is probably short for relocation iterator, but this is not an interator.
llvm-svn: 298786
Previously, relocation offsets are recalculated for .eh_frame sections
inside the main loop, and that messed up the main loop. This patch
separates that logic into a dedicated class.
llvm-svn: 298785
The original code is a big `if` and `else` which ends with `continue`
like this:
if (cond) {
...
// fall through
} else {
...
continue;
}
This patch rewrites it with the following.
if (!cond) {
...
continue;
}
...
llvm-svn: 298672
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
I honestly do not understand this part of code as it is too tangled.
What I'm trying now is to carefully disentangle it by transforming
code without changing meaining to see if I can improve overall
readability.
llvm-svn: 298576
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 is a shorthand for Config->Wordsize == 8. So this is not strictly
necessary but seems handy. "Is 64 bit?" is easier to read than "Is
wordsize 8 byte?"
llvm-svn: 298463
LinkerScript used to be a template class, so we couldn't instantiate
that class in elf::link. We instantiated ScriptConfig class earlier
instead so that the linker script parser can store configurations to
the object.
Now that LinkerScript is not a template, it doesn't make sense to
separate ScriptConfig from LinkerScript. This patch merges them.
llvm-svn: 298457
Patch moves Sections array to
InputFile (root class for input files).
That allows to detemplate GdbIndexSection.
Differential revision: https://reviews.llvm.org/D30976
llvm-svn: 298345
The patch introduces two new relocations expressions R_MIPS_GOT_GP and
R_MIPS_GOT_GP_PC. The first one represents a current value of `_gp`
pointer and used to calculate relocations against the `__gnu_local_gp`
symbol. The second one represents the offset between the beginning of
the function and the `_gp` pointer's value.
There are two motivations for introducing new expressions:
- It's better to keep all non-trivial relocation calculations in the
single place - `getRelocTargetVA` function.
- Relocations against both `_gp_disp` and `__gnu_local_gp` symbols
depend on the `_gp` value. It's a magical value points to the "middle"
of GOT. Now all relocations use a common `_gp` value. But in fact,
under some conditions each input file might require its own `_gp`
value. I'm going to implement it in the future patches. So it's
better to make `MipsGotSection` responsible for calculation of
the `_gp` value.
llvm-svn: 298306
This continues detemplation process.
Detemplating MipsGotSection<ELFT> is helpfull because can
help to detemplate getRelocTargetVA. (one more change is required)
It opens road to detemplation of GotSection<ELFT> and probably
something else after that.
Differential revision: https://reviews.llvm.org/D31090
llvm-svn: 298272
Does not introduce anything new,
just performs detemplate, using methods we
already have.
Differential revision: https://reviews.llvm.org/D30935
llvm-svn: 298269
We had a few Config member functions that returns configuration values.
For example, we had is64() which returns true if the target is 64-bit.
The return values of these functions are constant and never change.
This patch is to compute them only once to make it clear that they'll
never change.
llvm-svn: 298168
__start_xxx symbol keeps section xxx alive only if it is not
SHF_LINK_ORDER. Such sections can be used for user metadata, when
__start_xxx is used to iterate over section contents at runtime, and
the liveness is determined solely by the linked (associated) section.
This was earlier implemented in r294592, and broken in r296723.
Differential Revision: https://reviews.llvm.org/D30964
llvm-svn: 298154
Summary:
When we perform LTO builds with a version of ar that does not
understand LLVM bitcode objects, we end up with undefined references,
because our archive files do not list the bitcode symbols in their
indices. The error messages do not make it clear what the real problem
is. This change adds a note that points out the likely problem and
solution. It is similar in spirit to r282633, but aims to avoid false
positives by only triggering when we see both undefined references and
archives without symbols in their indices.
Fixes PR32281.
Reviewers: davide, ruiu, tejohnson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31011
llvm-svn: 298124
Do not take in account the `Live` flag while collecting .reginfo, .MIPS.options,
and .MIPS.abiflags input sections to produce corresponding output sections.
These sections have information purpose and should be always produced per
ABI requirements.
llvm-svn: 298093
With fix of next warning:
Writer.cpp:361:3: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
Original commit message:
Patch reuses BssSection section to simplify creation of
COMMON section.
Differential revision: https://reviews.llvm.org/D30690
llvm-svn: 298086
This fixes pr32031 by representing the expressions results as a
SectionBase and offset. This allows us to use an input section
directly instead of getting lost trying to compute an offset in an
outputsection when not all the information is available yet.
This also creates a struct to represent the *value* of and expression,
allowing the expression itself to be a simple typedef. I think this is
easier to read and will make it easier to extend the expression
computation to handle more complicated cases.
llvm-svn: 298079
Was fixed, details on review page.
Original commit message:
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 298062
This patch causes us to use pruneCache() to prune the ThinLTO cache after
completing LTO. A new flag --thinlto-cache-policy allows users to configure
the policy.
Differential Revision: https://reviews.llvm.org/D31021
llvm-svn: 298036
After the call to sys::fs::exists succeeds, indicating a cache hit, we call
AddFile and the client will open the file using the supplied path. If the
client is using cache pruning, there is a potential race between the pruner
and the client. To avoid this, change the caching API so that it provides
a MemoryBuffer to the client, and have clients use that MemoryBuffer where
possible.
This scheme won't work with the gold plugin because the plugin API expects a
file path. So we have the gold plugin use the buffer identifier as a path and
live with the race for now. (Note that the gold plugin isn't actually affected
by the problem at the moment because it doesn't support cache pruning.)
This effectively reverts r279883 modulo the change to use the existing path
in the gold plugin.
Differential Revision: https://reviews.llvm.org/D31063
llvm-svn: 298020
That allows to detemplate getGotPltOffset/getGotPltVA
methods of SymbolBody and also will help to detemplate
DynamicReloc itself later.
llvm-svn: 297946
Patch splits In<ELFT> into 2 classes: one for non-templated sections,
second contains ELFT templated ones.
That allows to code that was detemplated to access non-templated sections freely,
and should open road for futher detemplation proccess.
Differential revision: https://reviews.llvm.org/D30939
llvm-svn: 297844
After introducing Config->is64Bit() and
recent changes in LinkerScriptBase, some
sections can be detemplated trivially. This
is one of such cases.
llvm-svn: 297825
StringTableSection was <ELFT> templated previously,
It disallow to de-template code that uses it,
for example LinkerScript<ELFT>::discard uses it as:
if (S == In<ELFT>::ShStrTab)
error("discarding .shstrtab section is not allowed");
It seems we can try to detemplate some of synthetic sections
and somehow make them available for non-templated calls.
(move out of In<ELFT> struct probably).
Differential revision: https://reviews.llvm.org/D30933
llvm-svn: 297815
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 297814
Patch introduces Config->is64Bit() and with help of that detemplates
GotPltSection and IgotPltSection sections
Differential revision: https://reviews.llvm.org/D30944
llvm-svn: 297813
Rafael Espindola