The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Differential Revision: https://reviews.llvm.org/D44977
llvm-svn: 332351
The --keep-unique <symbol> option is taken from gold. The intention is that
<symbol> will be prevented from being folded by ICF. Although not
specifically mentioned in the documentation <symbol> only matches
global symbols, with a warning if the symbol is not found.
The implementation finds the Section defining <symbol> and removes it from
the set of sections considered for ICF.
Differential Revision: https://reviews.llvm.org/D46755
llvm-svn: 332332
This allows producing pdb debug info. This is an LLD specific option
since GCC and GNU binutils doesn't support the PDB file format.
Differential Revision: https://reviews.llvm.org/D46796
llvm-svn: 332327
Since we a no longer using this function for the wasm start
section we don't actually care what its signature is.
Differential Revision: https://reviews.llvm.org/D46594
llvm-svn: 332308
The relocation R_PPC64_REL64 should return R_PC for getRelExpr since it
computes S + A - P.
Differential Revision: https://reviews.llvm.org/D46766
llvm-svn: 332259
The relocation R_PPC64_REL32 should return R_PC for getRelExpr since it
computes S + A - P.
Differential Revision: https://reviews.llvm.org/D46586
llvm-svn: 332252
If a symbol with an undefined version in a DSO is not going to be
exported into the dynamic symbol table then do not give an error message
for the missing version. This can happen with the --exclude-libs option
which implicitly gives all symbols in a static library the local version.
This matches the behavior of ld.gold and is exploited by the Bionic
dynamic linker on Arm.
Differential Revision: https://reviews.llvm.org/D43126
llvm-svn: 332224
This is needed to avoid merging two functions with identical
instructions but different xdata. It also reduces binary size by
deduplicating identical pdata sections.
Fixes PR35337.
Differential Revision: https://reviews.llvm.org/D46672
llvm-svn: 332169
We discovered (crbug.com/838449#c24) that string tail merging can
negatively affect compressed binary size, so provide a flag to turn
it off for users who care more about compressed size than uncompressed
size.
Differential Revision: https://reviews.llvm.org/D46780
llvm-svn: 332149
Both R_PPC_CALL and R_PPC_CALL_PLT Exprs map to the R_PPC64_REL24 relocation
which has the form Sym + addend - P.
Differential Revision: https://reviews.llvm.org/D46654
llvm-svn: 332127
Summary:
Suppose we visit symbols in this order:
1. weak definition of foo in a lazy object
2. reference of foo
3 (optional). definition of foo
bfd/gold allows 123 but not 12.
Current --warn-backrefs implementation will report both cases as a backward reference. With this change, both 123 (intended) and 12 (unintended) are allowed. The usage of weak definitions usually imply there are also global definitions, so the trade-off is justified.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D46624
llvm-svn: 332061
The previous CL changes the order of output sections, which causes address changes in test cases.
Review: https://reviews.llvm.org/D46730
llvm-svn: 332054
This CL is to mitigate R_X86_64_PC32 relocation overflow problems for huge binaries that has near 4G allocated sections.
By examining those binaries, there're 2 issues contributes to the problem:
1). huge ".dynsym" and ".dynstr" stands in the way between .rodata and .text
2). _init_array_start/end are placed at 0 if no ".init_array" presents, this causes .text relocation against them become more prone to overflow.
This CL addresses 1st problem (the 2nd will be addressed in another CL.) by assigning a smaller sortrank to .dynsym and .dynstr thus they no longer stand in between.
llvm-svn: 332038
Merging data segments produces smaller code sizes because each segment
has some boilerplate. Therefore, merging data segments is generally the
right approach, especially with wasm where binaries are typically
delivered over the network.
However, when analyzing wasm binaries, it can be helpful to get a
conservative picture of which functions are using which data
segments[0]. Perhaps there is a large data segment that you didn't
expect to be included in the wasm, introduced by some library you're
using, and you'd like to know which library it was. In this scenario,
merging data segments only makes the analysis worse.
Alternatively, perhaps you will remove some dead functions by-hand[1]
that can't be statically proven dead by the compiler or lld, and
removing these functions might make some data garbage collect-able, and
you'd like to run `--gc-sections` again so that this now-unused data can
be collected. If the segments were originally merged, then a single use
of the merged data segment will entrench all of the data.
[0] https://github.com/rustwasm/twiggy
[1] https://github.com/fitzgen/wasm-snip
Patch by Nick Fitzgerald!
Differential Revision: https://reviews.llvm.org/D46417
llvm-svn: 332013
This is most useful when using lld-link on a non-Win host (but it might become
useful on Windows too if lld also grows a fansi-escape-codes flag).
Also make the help for --color-diagnostic mention the valid values in ELF and
wasm, and print the flag name with two dashes in diags, since the one-dash form
is seen as a list of many one-letter flags in some contexts.
https://reviews.llvm.org/D46693
llvm-svn: 332012
A non-alloc note section should not have a PT_NOTE program header.
Found while linking ghc (Haskell compiler) with lld on FreeBSD.
ghc emits a .debug-ghc-link-info note section (as the name suggests, it
contains link information) as a SHT_NOTE section without SHF_ALLOC set.
For this case ld.bfd does not emit a PT_NOTE segment for the
.debug-ghc-link-info section. lld previously emitted a PT_NOTE with
p_vaddr = 0 and FreeBSD's rtld segfaulted when trying to parse a note at
address 0.
llvm.org/pr37361
Differential Revision: https://reviews.llvm.org/D46623
llvm-svn: 331973
Reviewed by: ruiu, grimar, espindola
Differential Revision: https://reviews.llvm.org/D44562
Summary:
r331971 changes the debug line parser interface to report LLVM errors in an
interface that different executables can use, rather than always being printed
directly as warnings to stderr. This change allows LLD to make use of the new
interface and call its own warning methods to report problems.
llvm-svn: 331972
Previously this was only supported when specified on the command line
or in directives.
Differential Revision: https://reviews.llvm.org/D46244
llvm-svn: 331900
The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful for adding linker level aliases for function
in the import library) is a feature distinct and different from
the operator = used for exporting a function with a different
name (both in import library and DLL) than in the implementation
producing the DLL.
When creating an import library using dlltool, from a def file that
contains forwards (Func = OtherDll.Func), this shouldn't affect the
produced import library, which should still behave just as if it
was a normal exported function.
This clears a lot of confusion and subtle misunderstandings, and
avoids a parameter that was used to avoid creating weak aliases
when invoked from lld. (This parameter was added previously due to
the existing conflation of the two features.)
Differential Revision: https://reviews.llvm.org/D46245
llvm-svn: 331860
Adds support for .glink resolver stubs from the example implementation in the V2
ABI (Section 4.2.5.3. Procedure Linkage Table). The stubs are written to the
PltSection, and the sections are renamed to match the PPC64 ABI:
.got.plt --> .plt Type = SHT_NOBITS
.plt --> .glink
And adds the DT_PPC64_GLINK dynamic tag to the dynamic section when the plt is
not empty.
Differential Revision: https://reviews.llvm.org/D45642
llvm-svn: 331840
Separate output sections for selected text section prefixes to enable TLB optimizations and for readablilty.
Differential Revision: https://reviews.llvm.org/D45841
llvm-svn: 331823
Instead of writing empty index for file, this patch tracks the state of files in ObjectToIndexFileState. If the files are not indexed , only then we emit the empty files
Differential Revision: https://reviews.llvm.org/D46480
llvm-svn: 331803
Some MIPS relocations depend on "gp" value. By default, this value has
0x7ff0 offset from a .got section. But relocatable files produced by a
compiler or a linker might redefine this default value and we have to
use it for a calculation of the relocation result. When we generate EXE
or DSO it's trivial. Generating a relocatable output is more difficult
case because the linker does calculate relocations in this case and
cannot store individual "gp" values used by each input object file.
As a workaround we add the "gp" value to the relocation addend.
This fixes https://llvm.org/pr31149
Differential revision: https://reviews.llvm.org/D45972
llvm-svn: 331772
In the recognise test convert some ST1 multiple structure to ST1 single
structure to test the isST1SingleOpcode() function.
Differential Revision: https://reviews.llvm.org/D46263
llvm-svn: 331752
Nicola Zaghen