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
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 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
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
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
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
George Rimar