The xxHash64 function has been made unsigned-char-independent, so
we can reland this change now.
Original commit message:
> The icf-safe.s test currently fails on 32-bit platforms because it uses
> the --print-icf-sections flag and depends on the output appearing in
> a specific order. However, this flag causes the output to depend on
> the order of the sections in the Sections array, which depends on the
> hash values returned from hash_combine, which happen to be different
> for that test between 32-bit and 64-bit platforms.
>
> This change makes the output deterministic by using xxHash64 instead of
> hash_combine.
Differential Revision: https://reviews.llvm.org/D49877
llvm-svn: 338153
The icf-safe.s test currently fails on 32-bit platforms because it uses
the --print-icf-sections flag and depends on the output appearing in
a specific order. However, this flag causes the output to depend on
the order of the sections in the Sections array, which depends on the
hash values returned from hash_combine, which happen to be different
for that test between 32-bit and 64-bit platforms.
This change makes the output deterministic by using xxHash64 instead of
hash_combine.
Differential Revision: https://reviews.llvm.org/D49877
llvm-svn: 338088
Discard them unless they have been associated by other means (yet
uimplemented).
According to MS link.exe, such sections are illegal, but MinGW setups
use them in their take on associative comdats.
This avoids leaving references to the bogus SectionChunk* PendingComdat,
which cannot be dereferenced.
This fixes PR38183.
Differential Revision: https://reviews.llvm.org/D49653
llvm-svn: 338064
Patch by Andrew Kelley.
Previously, running lld::coff::link() twice in the same process would
access stale pointers because of these global variables not being reset.
After this patch, lld::coff::link() can be called any number of times,
just like its ELF and MACH-O counterparts.
Differential Revision: https://reviews.llvm.org/D49856
llvm-svn: 338042
We are already ICF'ing these sections as a unit with their dependent
sections, so they don't need to be considered for ICF individually.
This change also "fixes" slowness caused by our quadratic-in-group-size
relocation segregation algorithm on 32-bit ARM platforms with unwind
data and ICF on rodata. In this scenario almost every function's
.ARM.exidx is identical except for the targets of the relocations
that refer to the function and its .ARM.extab, which causes almost
all of the program's .ARM.exidx sections to be initially added to the
same class, which causes us to compare every such section with every
other such section.
Differential Revision: https://reviews.llvm.org/D49716
llvm-svn: 337967
Previously, the error messages didn't contain symbol name because we
didn't read a symbol name for these error messages.
Differential Revision: https://reviews.llvm.org/D49762
llvm-svn: 337863
If we fail to merge a secondary GOT with the primary GOT but so far only
one merged GOT has been created (the primary one), the final element in
MergedGots is the primary GOT. Thus we should not try to merge with this
final element passing IsPrimary=false, since this will ignore the fact
that the destination GOT does in fact need a header, and those extra two
entries can be enough to allow the merge to incorrectly occur. Instead
we should check for this case before attempting the second merge.
Patch by James Clarke.
Differential revision: https://reviews.llvm.org/D49422
llvm-svn: 337810
The gold behaviour with regard to --keep-unique is arguably a bug.
I also noticed a bug in my patch, which is that we mislink the
following program with --icf=safe by merging f3 and f4:
void f1() {}
void f2() {}
__attribute__((weak)) void* f3() { return f1; }
__attribute__((weak)) void* f4() { return f2; }
int main() {
printf("%p %p\n", f3(), f4());
}
llvm-svn: 337729
Signed values for the FDE PC addr were not correctly handled in
readFdeAddr(). If the value is negative and the type of the value is
smaller than 64 bits, the FDE PC addr overflow error would be
incorrectly triggered.
Fixed readFdeAddr() to properly handle signed values by sign extending
where appropriate.
Differential Revision: https://reviews.llvm.org/D49557
llvm-svn: 337683
Under --icf=all we now only apply KeepUnique to non-executable
address-significant sections. This has the effect of making --icf=all
mean unsafe ICF for executable sections and safe ICF for non-executable
sections.
With this change the meaning of the KeepUnique bit changes to
"does the current ICF mode (together with the --keep-unique and
--ignore-data-address-equality flags) require this section to be
kept unique".
Differential Revision: https://reviews.llvm.org/D49626
llvm-svn: 337640
The only restriction is that we cannot merge more than one KeepUnique
section together. This matches gold's behaviour and reduces code size
when using --icf=safe.
Differential Revision: https://reviews.llvm.org/D49622
llvm-svn: 337638
lld currently prepends the absolute path to itself to every diagnostic it
emits. This path can be longer than the diagnostic, and makes the actual error
message hard to read.
There isn't a good reason for printing this path: if you want to know which lld
you're running, pass -v to clang – chances are that if you're unsure of this,
you're not only unsure when it errors out. Some people want an indication that
the diagnostic is from the linker though, so instead print just the basename of
the linker's path.
Before:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
After:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
https://reviews.llvm.org/D49189
llvm-svn: 337634
If a binary is stripped, which can remove discardable sections (except
for the .reloc section, which also is marked as discardable as it isn't
loaded at runtime, only read by the loader), the .reloc section should
be first of them, in order not to create gaps in the image.
Previously, binaries with relocations were broken if they were stripped
by GNU binutils strip. Trying to execute such binaries produces an error
about "xx is not a valid win32 application".
This fixes GNU binutils bug 23348.
Prior to SVN r329370 (which didn't intend to have functional changes),
the code for moving discardable sections to the end didn't clearly
express how other discardable sections should be ordered compared to
.reloc, but the change retained the exact same end result as before.
After SVN r329370, the code (and comments) more clearly indicate that
it tries to make the .reloc section the absolutely last one; this patch
changes that.
This matches how GNU binutils ld sorts .reloc compared to dwarf debug
info sections.
Differential Revision: https://reviews.llvm.org/D49351
Signed-off-by: Martin Storsjö <martin@martin.st>
llvm-svn: 337598
For dwarf debug info, an executable normally either contains the debug
info, or it is stripped out. To reduce the storage needed (slightly)
for the debug info kept separately from the released, stripped binaries,
one can choose to only copy the debug data from the original executable
(essentially the reverse of the strip operation), producing a file with
only debug info.
When copying the debug data from an executable with GNU objcopy,
the build id and debug directory need to reside in a separate section,
as this will be kept while the rest of the .rdata section is removed.
Differential Revision: https://reviews.llvm.org/D49352
llvm-svn: 337526
This patch changes relative path for source files in obj files to
absolute path in PDB when linking with added flag.
I will make obj file generated by clang-cl independent from build
directory for chromium build. But I don't want to confuse visual studio
debugger or require additional configuration. To attain this goal, I
added flag to convert relative source file path in obj to absolute path
when emitting PDB.
By removing absolute path from obj files, we can share build cache
between chromium developers even when they are doing debug build.
That will make build time faster.
More context:
https://bugs.chromium.org/p/chromium/issues/detail?id=712796https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/5HXSVX-7fPc
llvm-svn: 337439
Dwarf debug info contains some data that contains absolute addresses.
Since these sections are discardable and aren't loaded at runtime,
there's no point in adding base relocations for them.
This makes sure that after stripping out dwarf debug info, there are no
base relocations that point to nonexistent sections.
Differential Revision: https://reviews.llvm.org/D49350
llvm-svn: 337438
Currently, getFdePC() returns uint64_t. Its because the following
encodings might use 8 bytes: DW_EH_PE_absptr and DW_EH_PE_udata8.
But caller assigns returned value to uint32_t field:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L508
Value is used for building .eh_frame_hdr section.
We use DW_EH_PE_sdata4 encoding for building it at this moment:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2545
And that means that an overflow issue might happen if
DW_EH_PE_absptr/DW_EH_PE_udata8 address encodings are present
in .eh_frame. In that case, before this patch, we silently would
truncate the address and produced broken .eh_frame_hdr section.
It would be not hard to support real 64-bit values for
DW_EH_PE_absptr/DW_EH_PE_udata8 encodings, but it is
unclear if it is usefull and if we should do it.
Since nobody faced/reported it, int this patch I only implement
a check to stop producing broken output silently for now.
llvm-svn: 337382
This is a part of ttps://bugs.llvm.org//show_bug.cgi?id=38119
We produce broken ELF header now when the number of output sections is >= SHN_LORESERVE (0xff00).
ELF spec says (http://www.sco.com/developers/gabi/2003-12-17/ch4.eheader.html):
e_shnum:
If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), this member has the value zero
and the actual number of section header table entries is contained in the sh_size field of the section header at index 0.
(Otherwise, the sh_size member of the initial entry contains 0.)
e_shstrndx
If the section name string table section index is greater than or equal to SHN_LORESERVE (0xff00), this member has the
value SHN_XINDEX (0xffff) and the actual index of the section name string table section is contained in the sh_link field of
the section header at index 0. (Otherwise, the sh_link member of the initial entry contains 0.)
We did not set these fields correctly earlier. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D49371
llvm-svn: 337363
Code was dead because at the moment of BssSection creation
it can never have a parent. Also, code simply does not
make sence as alignment adjastment happens when
BssSection is added to its parent later.
llvm-svn: 337276
There are following symbols currently available:
DefinedKind, SharedKind, UndefinedKind, LazyArchiveKind, LazyObjectKind.
Our code calls getSize() only for first two and there
seems to be no reason to return 0 for the rest.
llvm-svn: 337265
We did not try to support this intentionally but have
an error handling and reporting logic that can take care
of that and hence needs a test.
llvm-svn: 337250
Summary:
This removes the %T/dwo directory before calling ld.lld in ELF/lto/thinlto-debug-fission.ll so that
files aren't left over from previous runs.
Reviewers: espindola, pcc
Reviewed By: pcc
Subscribers: inglorion, emaste, arichardson, eraman, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49390
llvm-svn: 337210
Summary:
This adds support to option -plugin-opt=dwo_dir=${DIR}. This option is used to specify the directory to store the .dwo files when LTO and debug fission is used
at the same time.
Reviewers: ruiu, espindola, pcc
Reviewed By: pcc
Subscribers: eraman, dexonsmith, mehdi_amini, emaste, arichardson, steven_wu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47904
llvm-svn: 337195
Some Microsoft tools (e.g. new versions of WPA) fail when the
COFF Debug Directory contains a path to the PDB that contains
dots, such as D:\foo\./bar.pdb. Remove dots before writing this
path.
This fixes pr38126.
llvm-svn: 336873
Archives created with ThinLTO are bitcodes, they also need to be searched for excluded symbols.
Differential Revision: https://reviews.llvm.org/D48857
llvm-svn: 336826
If we have 2 bitcode inputs for different targets, LLD would
print "<internal>" instead of the name of one of the files.
The patch adds a test and fixes this issue.
llvm-svn: 336794
Since .gdb_index sections contain all known symbols, they can be very large.
One of my executables has a .gdb_index section of 1350 GiB. Uniquifying
symbols by name takes 3.77 seconds on my machine. This patch parallelize it.
Time to call createSymbols() with 8.4 million unique symbols:
Without this patch: 3773 ms
Parallelism = 1: 4374 ms
Parallelism = 2: 2628 ms
Parallelism = 16: 837 ms
As you can see above, this algorithm is a bit more inefficient
than the non-parallelized version, but even with dual-core, it is
faster than that, so I think it is overall a win.
Differential Revision: https://reviews.llvm.org/D49164
llvm-svn: 336790
This workaround is for GCC 5.4.1. Without this workaround, lld will
produce larger .gdb_index sections for object files compiled with the
buggy version of the compiler.
Since it is not for correctness, and it affects only debug builds (since
you are generating .gdb_index sections), perhaps the hack shouldn't have been
added in the first place. At least, I think it is time to remove this hack.
Differential Revision: https://reviews.llvm.org/D49149
llvm-svn: 336788
This patch merges createGdbIndex function and GdbIndexSection's
constructor into a single static member function of the class.
This patch also change how we keep CU vectors. Previously, CuVector
and GdbSymbols were parallel arrays, but there's no reason to choose that
design. Now, CuVector is a member of GdbSymbol class.
A lot of members are removed from GdbIndexSection. Previously, it has
members that need to be kept in sync over several phases. I belive the new
design is less error-prone, and the new code is much easier to read
than before.
llvm-svn: 336743
This fix add more test cases for routines check MIPS ELF header flags and
flags from .MIPS.abiflags sections. The tests use yaml2obj for object
files generation because not all combinations of flags can be produced
by LLVM tools.
llvm-svn: 336704
.gdb_index sections can be very large. When you are compiling
multi-gibibyte executables, they can be larger than 1 GiB. The previous
implementation of .gdb_index seems to consume too much memory.
This patch reduces memory consumption by eliminating temporary objects.
In one experiment, memory consumption of GdbIndexSection class is
reduced from 962 MiB to 228 MiB when creating a .gdb_index of 1350 GiB.
Differential Revision: https://reviews.llvm.org/D49094
llvm-svn: 336672
Future symbol insertions can potentially change the type of these
symbols - keep pointers to the base class to reflect this, and
use dynamic casts to inspect them before using as the subclass
type.
This fixes crashes that were possible before, by touching these
symbols that now are populated as e.g. a DefinedRegular, via
the old pointers with DefinedImportThunk type.
Differential Revision: https://reviews.llvm.org/D48953
llvm-svn: 336652
I believe the only way to test this functionality is to create extremely
large object files and attempt to create a .gdb_index that is greater
than 4 GiB. But I think that's too much for most environments and buildbots,
so I'm commiting this without a test that actually triggers the new
error condition.
llvm-svn: 336631
Previously, we didn't create multiple consecutive bitmaps.
Added a test to catch this bug too.
Differential Revision: https://reviews.llvm.org/D49107
llvm-svn: 336620
This patch also speeds it up by making some constants compile-time
constants. Other than that, NFC.
Differential Revision: https://reviews.llvm.org/D49101
llvm-svn: 336614
Patch by Matthew Koontz!
Before, direct calls to __wrap_sym would not map to valid PLT entries,
so they would crash at runtime. This change maps such calls to the same
PLT entry as calls to sym that are then wrapped.
Differential Revision: https://reviews.llvm.org/D48502
llvm-svn: 336609
Patch by Rahul Chaudhry!
This change adds experimental support for SHT_RELR sections, proposed
here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg
Pass '--pack-dyn-relocs=relr' to enable generation of SHT_RELR section
and DT_RELR, DT_RELRSZ, and DT_RELRENT dynamic tags.
Definitions for the new ELF section type and dynamic array tags, as well
as the encoding used in the new section are all under discussion and are
subject to change. Use with caution!
Pass '--use-android-relr-tags' with '--pack-dyn-relocs=relr' to use
SHT_ANDROID_RELR section type instead of SHT_RELR, as well as
DT_ANDROID_RELR* dynamic tags instead of DT_RELR*. The generated
section contents are identical.
'--pack-dyn-relocs=android+relr --use-android-relr-tags' enables both
'--pack-dyn-relocs=android' and '--pack-dyn-relocs=relr': lld will
encode the relative relocations in a SHT_ANDROID_RELR section, and pack
the rest of the dynamic relocations in a SHT_ANDROID_REL(A) section.
Differential Revision: https://reviews.llvm.org/D48247
llvm-svn: 336594
This patch adds the target call back relaxTlsLdToLe to support TLS relaxation
from local dynamic to local exec model.
Differential Revision: https://reviews.llvm.org/D48293
llvm-svn: 336559
The reference implementation uses a case-insensitive string
comparison for strings of equal length. This will cause the
string "tEo" to compare less than "VUo". However we were using
a case sensitive comparison, which would generate the opposite
outcome. Switch to a case insensitive comparison. Also, when
one of the strings contains non-ascii characters, fallback to
a straight memcmp.
The only way to really test this is with a DIA test. Before this
patch, the test will fail (but succeed if link.exe is used instead
of lld-link). After the patch, it succeeds even with lld-link.
llvm-svn: 336464
They were failing in Chromium's packaging builds with:
C:\b\rr\tmphqfaff\w\src\third_party\llvm\tools\lld\test\COFF\pdb-globals-dia-vfunc-collision2.test:24:8:
error: expected string not found in input
CHECK: func [0x00001060+ 0 - 0x0000106c-12 | sizeof= 12] (FPO) virtual int __cdecl A132()
^
<stdin>:8:11: note: scanning from here
struct S [sizeof = 8] {
^
<stdin>:9:2: note: possible intended match here
func [0x00001060+ 0 - 0x0000106c-12 | sizeof= 12] (FPO) virtual int __cdecl S::A132()
^
Maybe due to different DIA versions.
llvm-svn: 336424
Remove support for linking microMIPS 64-bit code because this kind of
ISA is rarely used and unsupported by LLVM.
Differential revision: https://reviews.llvm.org/D48949
llvm-svn: 336413
We add an option to dump the entire global / public symbol record
stream. Previously we would dump globals or publics, but not both.
And when we did dump them, we would always dump them in the order
they were referenced by the corresponding hash streams, not in
the order they were serialized in. This patch adds a lower level
mode that just dumps the whole stream in serialization order.
Additionally, when dumping global-extras, we now dump the hash
bitmap as well as the record offset instead of dumping all zeros
for the offsets.
llvm-svn: 336407
It seems like the debugger first computes a symbol's bucket,
and then does a binary search of entries in the bucket using the
symbol's name in order to find it. If the bucket entries are not
in sorted order, this obviously won't work. After this patch a
couple of simple test cases show that we generate an exactly
identical GSI hash stream, which is very nice.
llvm-svn: 336405
In this file we only have to handle the v2 ABI, so what we need to do
is to just make sure that all object files have v2 or unspecified version
number.
Differential Revision: https://reviews.llvm.org/D48112
llvm-svn: 336372
We call switchTo() from assignAddresses() for switching to Aether,
and from assignOffsets().
First calls assignOffsets() one by one for each output section.
(https://github.com/llvm-mirror/lld/blob/master/ELF/LinkerScript.cpp#L1045)
That I believe means the condition removed in this patch is dead.
llvm-svn: 336356
Currently, there are only OutputSection and SymbolAssignment
commands possible at the first level under SECTIONS tag.
Hence, dyn_cast was excessive.
llvm-svn: 336354
Test case ensures lld generates an error if unable to
write an empty index file for lazy object file that is not added to link.
This covers the following line with a test:
https://github.com/llvm-mirror/lld/blob/master/ELF/LTO.cpp#L206
llvm-svn: 336340
I think code is dead, because the only way to see
Path as empty seems would be if replaceThinLTOSuffix()
replaced some prefix with empty prefix (making the result
Path empty).
But it is impossible to pass the empty prefix,
we would file in driver:
https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L669
llvm-svn: 336338
This is https://bugs.llvm.org//show_bug.cgi?id=37836
Previously LLD could assign to Dot or set the address
for the section with address expression but did not advance
the position in a memory region.
Patch fixes the issue.
llvm-svn: 336335
Currently, there are only OutputSection and SymbolAssignment
commands possible at the first level under SECTIONS tag.
So, shouldSkip() contained dead "return true".
Patch simplifies the code.
llvm-svn: 336282
We did not have a test that would test that
_etext address is equal to etext, _end == end and _edata == edata.
Because of that, the following line was never
executed when running our tests:
https://github.com/llvm-mirror/lld/blob/master/ELF/Writer.cpp#L928
Patch fixes that.
llvm-svn: 336280
We have a following comment for createEmptyIndex caller code:
// If LazyObjFile has not been added to link, emit empty index files.
// This is needed because this is what GNU gold plugin does and we have a
// distributed build system that depends on that behavior.
Though createEmptyIndex() itself
(https://github.com/llvm-mirror/lld/blob/master/ELF/LTO.cpp#L202)
is never called in our test cases.
Patch adds a test.
llvm-svn: 336270
ELF spec doesn't allow a relocation to point to a deduplicated
COMDAT section. Unfortunately this happens in practice (e.g. .eh_frame)
We have a code in MarkLive.cpp for that and it was uncovered by any test case:
https://github.com/llvm-mirror/lld/blob/master/ELF/MarkLive.cpp#L199
Patch adds a test.
llvm-svn: 336259
LLD removes empty output sections otherwise specified in the linker
script. Prior to this change however, if section descriptions included
ANY kind of symbol assignment, then the consequent output section would
not be removed, even if the assignment was marked with PROVIDE and not
actually triggered (i.e. the symbol was never referenced). This change
modifies the isDiscarable function to ignore such directives when
determining whether a section should be discarded, in keeping with
bfd's behaviour. Symbol assignments that do result in a symbol
definition will continue to result in a kept section (this is not
actually the same as bfd's behaviour, but it is simpler, and probably
makes more sense).
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D48771
llvm-svn: 336184
The AArch64 -fix-cortex-a53-843419 is missing a test case for the load and
store exclusive instructions. This was leading to a function not being
covered in the codebase. This change adds two new instruction sequences to
be recognised as an instance of the erratum, one with a load exclusive the
other with a store exclusive.
Differential Revision: https://reviews.llvm.org/D48840
llvm-svn: 336181
Comment in the test case says that:
## This inputs previously created a 4gb temporarily file under 32 bit
## configuration. Issue was fixed. There is no clean way to check that from here.
## This testcase added for documentation purposes.
The intention of the test was to create such huge file
in case if our code will be broken again.
And currently it documents we do not create huge outputs.
r336129 changed -o to /dev/null and broke the intentions of the test case.
llvm-svn: 336179
We have the following code that is uncovered with the test:
https://github.com/llvm-mirror/lld/blob/master/ELF/Target.cpp#L95
This patch:
1) Removes "!IS" check. Because at that point of execution
(we are reolving the relocations during writing output)
we should only have InputSection type of the sections in the vector.
(because we already converted MergeInputSection in mergeSections()
and combined EhInputSections in combineEhFrameSections()).
2) Covers the "!IS->getParent()" with the test.
llvm-svn: 336106
CIEs augmentation string can have 'P' character,
what means the next byte is the personality encoding, a DW_EH_PE_xxx value.
This is followed by a pointer to the personality function.
We had the support of the different encodings earlier, but had no test cases.
This change adds coverage of DW_EH_PE_absptr/DW_EH_PE_signed/DW_EH_PE_udata2/DW_EH_PE_sdata2 and
DW_EH_PE_udata8/DW_EH_PE_sdata8 cases for place below:
https://github.com/llvm-mirror/lld/blob/master/ELF/EhFrame.cpp#L123
llvm-svn: 335969
I do not think this code was ever alive,
because the following code says we can have OutputSection and
SymbolAssignment cases only. We already handle both of them.
https://github.com/llvm-mirror/lld/blob/master/ELF/ScriptParser.cpp#L502
FWIW, it is dead in the LLD code coverage reports I am running either.
llvm-svn: 335958
In this mode, we retain the symbol table, but skip the actual debug
information.
Differential Revision: https://reviews.llvm.org/D48745
llvm-svn: 335947
With this set, we retain the symbol table, but skip the actual debug
information.
This is meant to be used by the MinGW frontend.
Differential Revision: https://reviews.llvm.org/D48745
llvm-svn: 335946
This change effects the behavior of --export-all. Previously
--export-all would only effect symbols that survived GC. Now
--export-all will prevent any non-local symbols from being GCed.
Differential Revision: https://reviews.llvm.org/D48673
llvm-svn: 335878
Peter Collingbourne