Unlike GNU tar and libarchive bsdtar, NetBSD 'tar -t' output does not
use C-style escapes and instead outputs paths literally. Fix the test
to account both for escaped and literal backslash output.
Differential Revision: https://reviews.llvm.org/D55441
llvm-svn: 348628
This was a missing piece.
We started to print LMAs and information about assignments,
but did not do that for assignments outside of section declarations yet.
The patch implements it.
Differential revision: https://reviews.llvm.org/D45314
llvm-svn: 348468
The test breaks on buildbots that don't enable the x86 backend. Other
tests in this directory explicitly require x86, so this should do the
trick.
llvm-svn: 348466
This is a part of
https://bugs.llvm.org/show_bug.cgi?id=39885
Linker script specification says:
"You can specify a file name to include sections from a particular file. You would
do this if one or more of your files contain special data that needs to be at a
particular location in memory."
LLD did not accept this syntax. The patch implements it.
Differential revision: https://reviews.llvm.org/D55324
llvm-svn: 348463
Previously these were dropped. We now understand them sufficiently
well to start emitting them. From the debugger's perspective, this
now enables us to have debug info about typedefs (both global and
function-locally scoped)
Differential Revision: https://reviews.llvm.org/D55228
llvm-svn: 348306
Patch from Andrew Kelley.
For context, see https://bugs.llvm.org/show_bug.cgi?id=39862
The use case is embedded / OS programming where the kernel wants
access to its own debug info via mapped dwarf info. I have a proof of
concept of this working, using this linker script snippet:
.rodata : ALIGN(4K) {
*(.rodata)
__debug_info_start = .;
KEEP(*(.debug_info))
__debug_info_end = .;
__debug_abbrev_start = .;
KEEP(*(.debug_abbrev))
__debug_abbrev_end = .;
__debug_str_start = .;
KEEP(*(.debug_str))
__debug_str_end = .;
__debug_line_start = .;
KEEP(*(.debug_line))
__debug_line_end =
.;
__debug_ranges_start
= .;
KEEP(*(.debug_ranges))
__debug_ranges_end
= .;
}
Differential revision: https://reviews.llvm.org/D55276
llvm-svn: 348291
When linking the linux kernel on ppc64le
ld.lld -EL -m elf64lppc -Bstatic --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
built-in.a --no-whole-archive --start-group lib/lib.a --end-group
ld.lld: error: discarding .rela.plt section is not allowed
The linker script discards with the following matches
*(.glink .iplt .plt .rela* .comment)
Differential Revision: https://reviews.llvm.org/D54871
llvm-svn: 348258
When linking the linux kernel on ppc64 and ppc
ld.lld: error: unrecognized reloc 11
11 is PPC_REL14 and PPC64_REL14
Differential revision: https://reviews.llvm.org/D54868
llvm-svn: 348255
At least on Linux, if a file size given to FileOutputBuffer is greater
than 2^63, it fails with "Invalid argument" error, which is not a
user-friendly error message. With this patch, lld prints out "output
file too large" instead.
llvm-svn: 348153
Now LLD might build the broken/incomplete .gdb_index when some DWARF v5
sections (like .debug_rnglists and .debug_addr) are used.
Particularly, for the case above, we emit an empty address area.
A test case is provided and patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55109
llvm-svn: 348119
We initialize .text section with 0xcc (INT3 instruction), so we need to
explicitly write data even if it is zero if it can be in a .text section.
If you specify /merge:.rdata=.text, .rdata (which contains .idata) is put
to .text, so we need to do this.
Fixes https://bugs.llvm.org/show_bug.cgi?id=39826
Differential Revision: https://reviews.llvm.org/D55098
llvm-svn: 348000
The _GLOBAL_OFFSET_TABLE_ is a linker defined symbol that is placed at
some location relative to the .got, .got.plt or .toc section. On some
targets such as Arm the correctness of some code sequences using a
relocation to _GLOBAL_OFFSET_TABLE_ depend on the value of the symbol
being in the linker defined place. Follow the ld.gold example and give
a multiple symbol definition error. The ld.bfd behaviour is to ignore the
definition in the input object and redefine it, which seems like it could
be more surprising.
fixes pr39587
Differential Revision: https://reviews.llvm.org/D54624
llvm-svn: 347854
Summary:
This reinstates what I originally intended to do in D54361.
It removes the assumption that .debug_gnu_pubnames has increasing CuOffset.
Now we do better than gold here: when .debug_gnu_pubnames contains
multiple sets, gold would think every set has the same CU index as the
first set (incorrect).
Reviewed By: ruiu
Reviewers: ruiu, dblaikie, espindola
Subscribers: emaste, arichardson, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54483
llvm-svn: 347820
The DT_PLTRELSZ dynamic tag is calculated using the size of the
OutputSection containing the In.RelaPlt InputSection. This will work for the
default no linker script case and the majority of linker scripts.
Unfortunately it doesn't work for some 'almost' sensible linker scripts. It
is permitted by ELF to have a single OutputSection containing both
In.RelaDyn, In.RelaPlt and In.RelaIPlt. It is also permissible for the range
of memory [DT_RELA, DT_RELA + DT_RELASZ) and the range
[DT_JMPREL, DT_JMPREL + DT_JMPRELSZ) to overlap as long as the the latter
range is at the end.
To support this type of linker script use the specific InputSection sizes.
Fixes pr39678
Differential Revision: https://reviews.llvm.org/D54759
llvm-svn: 347736
The number of sections is used in assignAddresses (in
finalizeAddresses) and the space for all sections is permanent from
that point on, even if we later decide we won't write some of them.
The VirtualSize field also gets calculated in assignAddresses, so we
need to manually check whether the section is empty here instead.
Differential Revision: https://reviews.llvm.org/D54495
llvm-svn: 347704
This is https://bugs.llvm.org/show_bug.cgi?id=38074.
The issue is that when calling a function, LLD generates a
.got entry that points to the IFUNC resolver function when
instead, it should use the PLT entries properly for
handling the IFUNC.
So we should create a got entry that points to PLT entry,
which itself loads the value from
.got.plt, relocated with R_*_IRELATIVE to make things work.
Patch do that.
Differential revision: https://reviews.llvm.org/D54314
llvm-svn: 347650
The changes to the instructions performed by TLS relaxation and the errata
patching are performed with relocations. As these are applied so late the
errata scanning won't see the changes in the section data made by the TLS
relaxation. This can lead to a TLS relaxed sequence being patched when it
doesn't need to be.
The fix checks to see if there is a R_RELAX_TLS_IE_TO_LE instruction at the
same address as the ADRP as this indicates the presence of a relaxation
of a sequence that might get recognised as a patch.
Differential Revision: https://reviews.llvm.org/D54854
llvm-svn: 347649
This is https://bugs.llvm.org//show_bug.cgi?id=38978
Spec says that:
"Objects may be built with the -z nodefaultlib option to
suppress any search of the default locations at runtime.
Use of this option implies that all the dependencies of an
object can be located using its runpaths.
Without this option, which is the most common case, no
matter how you augment the runtime linker's library
search path, its last element is always /usr/lib for 32-bit
objects and /usr/lib/64 for 64-bit objects."
The patch implements this option.
Differential revision: https://reviews.llvm.org/D54577
llvm-svn: 347647
GNU ld, which doesn't generate PDBs, can optionally generate a
build id by passing the --build-id option. LLD's MinGW frontend knows
about this option but ignores it, as I had falsely assumed that LLD
already generated build IDs even in those cases.
If debug info is requested and no PDB path is set, generate a
build id signature as a hash of the binary itself. This allows
associating a binary to a minidump, even if debug info isn't
written in PDB form by the linker.
Differential Revision: https://reviews.llvm.org/D54828
llvm-svn: 347645
Summary:
MSVC does this, and we should to.
The .gfids table is a table of RVAs, so it's impossible for a DLL to
indicate that an imported symbol is address taken. Therefore, exports
appear to be listed as address taken by the DLL that exports them.
This fixes an issue that Firefox ran into here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485016#c12
In Firefox, the export directive came from a .def file, but we need to
do this for any kind of export.
Reviewers: dmajor, hans, amccarth, alex
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54723
llvm-svn: 347623
When we are in a error state, script parser will not parse the -defsym
expression and hence will not tokenize it. Then ScriptLexer::Pos will be 0
and LLD will assert and crash here:
MemoryBufferRef ScriptLexer::getCurrentMB() {
assert(!MBs.empty() && Pos > 0); // Bang !
Solution - stop parsing the defsym in a error state. That is consistent
with the regular case (when we parse the linker script).
llvm-svn: 347549
Summary:
This fixes PR39711: -static -z retpolineplt does not produce retpoline PLT header.
-z now is not relevant.
Statically linked executable does not have PLT, but may have IPLT with no header. When -z retpolineplt is specified, however, the repoline PLT header should still be emitted.
I've checked that this fixes the FreeBSD reproduce in PR39711 and a Linux program statically linked against glibc. The programm print "Hi" rather than SIGILL/SIGSEGV.
getPltEntryOffset may look dirty after this patch, but it can be cleaned up later.
Another possible improvement is that when there are non-preemptible IFUNC symbols (rare case, e.g. -Bsymbolic), both In.Plt and In.Iplt can be non-empty and we'll emit the retpoline PLT header twice.
Reviewers: espindola, emaste, chandlerc, ruiu
Reviewed By: emaste
Subscribers: emaste, arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D54782
llvm-svn: 347404
When REQUIRES: ARM is used the test is skipped as ARM is not recognized.
Change to REQUIRES: arm so that it is run. This required updating one of the
tests due to changes in expected output.
Differential Revision: https://reviews.llvm.org/D54786
llvm-svn: 347388
Summary:
When --noinhibit-exec is used, ld.bfd/gold emit errors but allow to produce corrupted executable, which is handy for debugging purpose. lld's --noinhibit-exec has a different meaning and changes some errors to warnings. This patch replaces "error" with "errorOrWarn" to exploit that property.
We may revisit this: if we should keep them as errors (as ld.bfd/gold do) but allow to produce a (corrupted) executable.
Reviewers: ruiu, grimar, espindola
Reviewed By: grimar
Subscribers: Timmmm, jhenderson, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D54651
llvm-svn: 347327
Summary: This patch implementation the handler for ARM_V4BX. This relocation is used by GNU runtime files and other armv4 applications.
Patch by Yin Ma
Reviewers: espindola, MaskRay, ruiu, peter.smith, pcc
Reviewed By: ruiu
Subscribers: yinma, pcc, peter.smith, MaskRay, rovka, efriedma, emaste, javed.absar, arichardson, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D53444
llvm-svn: 347077
Current value using as a trap instruction (0xefefefef) is not a good choice
for MIPS because it's a valid MIPS instruction `swc3 $15,-4113(ra)`. This
patch replaces 0xefefefef by 0x04170001. For all MIPS ISA revisions before
R6, this value is just invalid instruction. Starting from MIPS R6 it's
a valid instruction `sigrie 1` which signals a Reserved Instruction exception.
mips-traps.s test case is added to test trap encoding. Other test cases
are modified to remove redundant checking.
Differential revision: https://reviews.llvm.org/D54154
llvm-svn: 347029
On PowerPC64, when a function call offset is too large to encode in a call
instruction the address is stored in a table in the data segment. A thunk is
used to load the branch target address from the table relative to the
TOC-pointer and indirectly branch to the callee. When linking position-dependent
code the addresses are stored directly in the table, for position-independent
code the table is allocated and filled in at load time by the dynamic linker.
For position-independent code the branch targets could have gone in the .got.plt
but using the .branch_lt section for both position dependent and position
independent binaries keeps it consitent and helps keep this PPC64 specific logic
seperated from the target-independent code handling the .got.plt.
Differential Revision: https://reviews.llvm.org/D53408
llvm-svn: 346877
The R_AARCH64_ADR_PREL_PG_HI21 relocation type is given the R_PAGE_PC
RelExpr. This can be transformed to R_PLT_PAGE_PC via toPlt().
Unfortunately the resolution is identical to R_PAGE_PC so instead of
getting the address of the PLT entry we get the address of the symbol
which may not be correct in the case of static ifuncs. The fix is to
handle the cases separately and use getPltVA() + A with R_PLT_PAGE_PC.
Differential Revision: https://reviews.llvm.org/D54474
llvm-svn: 346863
gdb-index-multiple-cu-2.s puts the symbol in question to another object file %t1.o, so that its CuIndex is affected by the number of CUs in %t.o
Also change `Kind:` in a comment to `Attributes:` as a follow-up of D54480 and D54481
llvm-svn: 346796
Summary:
Idx passed to readPubNamesAndTypes was an index into Chunks, not an
index into the CU list. This would be incorrect if some .debug_info
section contained more than 1 DW_TAG_compile_unit.
In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds.
Without this patch, any application linking such Scrt1.o would have invalid .gdb_index
The issue could be demonstrated by:
(gdb) py print(gdb.lookup_global_symbol('main'))
None
Reviewers: espindola, ruiu
Reviewed By: ruiu
Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54361
llvm-svn: 346747
`--no-demangle` now also applies to the name section. This change
was motivated by the rust team that have a slightly different name
mangling scheme to the standard C++ itanium one and prefer to do their
de-mangling as a post-link setp.
Patch by Alex Crichton!
Differential Revision: https://reviews.llvm.org/D54279
llvm-svn: 346516
Summary:
Reuse the "referenced by" note diagnostic code that we already use for
undefined symbols. In my case, it turned this:
lld-link: error: relocation against symbol in discarded section: .text
lld-link: error: relocation against symbol in discarded section: .text
...
Into this:
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
...
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
...
I think the new output is more useful.
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54240
llvm-svn: 346427
Used for WebAssembly threads proposal. Add a flag --shared-memory
which sets the IS_SHARED bit in WasmLimits
Differential Revision: https://reviews.llvm.org/D54130
llvm-svn: 346248
Summary: llvm-readobj/readelf accepts both -s and -S as aliases for --sections. However with GNU readelf only -S means --section, and -s means --symbols. I would like to make llvm-readelf more compatible.
Reviewers: MaskRay, espindola
Reviewed By: MaskRay
Subscribers: emaste, arichardson, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D54118
llvm-svn: 346164
This change allows for link-time merging of debugging information from
Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu.
This fixes llvm.org/PR34278
Differential Revision: https://reviews.llvm.org/D45213
llvm-svn: 346154
Summary:
It is difficult to touch a file with a relative mtime across different OSes as POSIX touch -d is rigid. While we may construct relative timestamps with `date`, POSIX date is inadequate to do so as various OSes' date do not agree on a common format (OpenBSD uses `date -r seconds`, FreeBSD uses `date -v-2M` while GNU accepts `-d '-2 min'`)
Just use python os.utime()
Original description:
The case may randomly fail if we test it with command "
while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect.
However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3.
The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
The same fix is applied to llvm code at https://reviews.llvm.org/D52452.
Patch by Luo Yuanke.
Reviewers: ruiu, craig.topper, smaslov, Jianping, espindola, LuoYuanke, tejohnson
Reviewed By: tejohnson
Subscribers: sbc100, krytarowski, aheejin, llvm-commits, dexonsmith, steven_wu, arichardson, inglorion, emaste, bjope, rupprecht
Differential Revision: https://reviews.llvm.org/D54039
llvm-svn: 346006
Summary:
The case may randomly fail if we test it with command "
while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect.
However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3.
The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
The same fix is applied to llvm code at https://reviews.llvm.org/D52452.
Patch by Luo Yuanke.
Reviewers: ruiu, craig.topper, smaslov, Jianping, espindola, LuoYuanke
Subscribers: rupprecht, bjope, emaste, inglorion, arichardson, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D53123
llvm-svn: 345977
Summary:
D52830 sets sh_link to .symtab in static link, which breaks executable stripped by GNU strip.
It may also be odd that .rela.plt (SHF_ALLOC) points to .symtab (non-SHF_ALLOC).
Change the logic on pcc's suggestion.
Before:
% clang -fuse-ld=lld -static -xc =(printf 'int main(){}') # or gcc
% strip a.out; ./a.out
unexpected reloc type in static binary[1] 61634 segmentation fault ./a.out
Reviewers: ruiu, grimar, emaste, espindola
Reviewed By: ruiu
Subscribers: pcc, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53993
llvm-svn: 345899
This is https://bugs.llvm.org/show_bug.cgi?id=39493.
We crashed previously because did not handle /DISCARD/ properly
when -r was used. I think it is uncommon to use scripts with -r, though I see
nothing wrong to handle the /DISCARD/ so that we will not crash at least.
Differential revision: https://reviews.llvm.org/D53864
llvm-svn: 345819
Summary: .rela.plt may only contain R_*_{,I}RELATIVE relocations and not need a symbol table link. bfd/gold fallbacks to sh_link=0 in this case. Without this patch, ld.lld --strip-all caused lld to dereference a null pointer.
Reviewers: ruiu, grimar, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53881
llvm-svn: 345648
Summary: There are too many reasonable cases that would be considered unorderable.
Reviewers: ruiu, espindola, Bigcheese
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53669
llvm-svn: 345322
Out::DebugInfo was used only by GdbIndex class to determine if
we need to create a .gdb_index section, but we can do the same
check without it.
Added a test that this patch doesn't change the existing behavior.
llvm-svn: 345058
Summary:
During upgrading of the FreeBSD source tree with lld 7.0.0, I noticed
that it started complaining about `crt1.o` having an "index past the
end of the symbol table".
Such a symbol table looks approximately like this, viewed with `readelf
-s` (note the `Ndx` field being messed up):
```
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_end
3: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_start
```
At first, it seemed that recent ifunc relocation work had caused this:
<https://reviews.freebsd.org/rS339351>, but it turned out that it was
due to incorrect processing of the object files by lld, when using `-r`
(a.k.a. --relocatable).
Bisecting showed that rL324421 ("Convert a use of Config->Static") was
the commit where this new behavior began. Simply reverting it solved
the issue, and the `__rel_iplt` symbols had an index of `UND` again.
Looking at Rafael's commit message, I think he simply missed the
possibility of `--relocatable` being in effect, so I have added an
additional check for it.
I also added a simple regression test case.
Reviewers: grimar, ruiu, emaste, espindola
Reviewed By: ruiu
Subscribers: arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D53515
llvm-svn: 345002
emulation.s is testing multiple architectures, which means it needs all
the corresponding backends enabled, which might not be true for all
developers (for example, I don't have PPC or MIPS enabled). Rather than
marking the entire test as unsupported for such developers, split it up
per backend to get better testing granularity.
Differential Revision: https://reviews.llvm.org/D53544
llvm-svn: 344986
Turns out I wasn't actually running this test locally, since I don't
build the PPC and MIPS backends. Whoops.
Perhaps this test should be split up per-architecture?
llvm-svn: 344980
We need this to support 32-bit ARM. Add test cases for emulation
handling for this architecture as well.
Differential Revision: https://reviews.llvm.org/D53539
llvm-svn: 344976
Summary:
Before, superfluous warnings were emitted for the following two cases:
1) When from symbol was in a discarded section.
The profile should be thought of as affiliated to the section.
It makes sense to ignore the profile if the section is discarded.
2) When to symbol was in a shared object.
The object file containing the profile may not know about the to
symbol, which can reside in another object file (useful profile) or a
shared object (not useful as symbols in the shared object are fixed
and unorderable). It makes sense to ignore the profile from the object
file.
Note, the warning when to symbol was undefined was suppressed in
D53044, which is still useful for --symbol-ordering-file=
This patch silences the warnings. The check is actually more relaxed (no
warnings if either From or To is not Defined) for simplicity and I don't
see a compelling reason to warn on more cases.
Reviewers: ruiu, davidxl, espindola, Bigcheese
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53470
llvm-svn: 344974
This patch adds a support for OUTPUT_FORMAT linker script directive.
Since I'm not 100% confident with BFD names you can use in the directive
for all architectures, I added only a few in this patch. We can add
other names for other archtiectures later.
We still do not support triple-style OUTPUT_FORMAT directive, namely,
OUTPUT_FORMAT(bfdname, big, little). If you pass -EL (little endian)
or -EB (big endian) to the linker, GNU linkers pick up big or little
as a BFD name, correspondingly, so that you can use a single linker
script for bi-endian processor. I'm not sure if we really need to
support that, so I'll leave it alone for now.
Note that -m takes precedence over OUTPUT_FORAMT, but we always parse
a BFD name given to OUTPUT_FORMAT for error checking. You cannot write
an invalid name in the OUTPUT_FORMAT directive.
Differential Revision: https://reviews.llvm.org/D53495
llvm-svn: 344952
Normally one wouldn't run into that case, but it is possible with
a little creative ordering of special libraries.
Differential Revision: https://reviews.llvm.org/D53388
llvm-svn: 344776
Adjusted the range check on a call instruction from 24 bits signed to
26 bits signed. While the instruction only encodes 24 bits, the target is
assumed to be 4 byte aligned, and the value that is encoded in the instruction
gets shifted left by 2 to form the offset. Also added a check that the offset is
indeed at least 4 byte aligned.
Differential Revision: https://reviews.llvm.org/D53401
llvm-svn: 344747
All the PassBuilder::parse interfaces now return descriptive StringError
instead of a plain bool. It allows to make -passes/aa-pipeline parsing
errors context-specific and thus less confusing.
TODO: ideally we should also make suggestions for misspelled pass names,
but that requires some extensions to PassBuilder.
Reviewed By: philip.pfaffe, chandlerc
Differential Revision: https://reviews.llvm.org/D53246
llvm-svn: 344685
Recommitting https://reviews.llvm.org/rL344544 after fixing undefined behavior
from left-shifting a negative value. Original commit message:
This support is slightly different then the X86_64 implementation in that calls
to __morestack don't need to get rewritten to calls to __moresatck_non_split
when a split-stack caller calls a non-split-stack callee. Instead the size of
the stack frame requested by the caller is adjusted prior to the call to
__morestack. The size the stack-frame will be adjusted by is tune-able through a
new --split-stack-adjust-size option.
llvm-svn: 344622
This reverts commit https://reviews.llvm.org/rL344544, which causes failures on
a undefined behaviour sanitizer bot -->
lld/ELF/Arch/PPC64.cpp:849:35: runtime error: left shift of negative value -1
llvm-svn: 344551
This support is slightly different then the X86_64 implementation in that calls
to __morestack don't need to get rewritten to calls to __moresatck_non_split
when a split-stack caller calls a non-split-stack callee. Instead the size of
the stack frame requested by the caller is adjusted prior to the call to
__morestack. The size the stack-frame will be adjusted by is tune-able through a
new --split-stack-adjust-size option.
Differential Revision: https://reviews.llvm.org/D52099
llvm-svn: 344544
This is https://bugs.llvm.org/show_bug.cgi?id=39289.
Currently both gold and bfd report errors about invalid options values
even with -v/-versions. But LLD does not.
This makes complicated to check the options available when LLD is used.
Patch makes LLD behavior to be consistent with GNU linkers.
Differential revision: https://reviews.llvm.org/D53278
llvm-svn: 344514
This a resubmission of a patch which was previously reverted
due to breaking several lld tests. The issues causing those
failures have been fixed, so the patch is now resubmitted.
---Original Commit Message---
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344377
If you have the string /usr/bin, prior to this patch it would not
be quoted by our YAML serializer. But a string like C:\src would
be, due to the presence of a backslash. This makes the quoting
rules of basically every single file path different depending on
the path syntax (posix vs. Windows).
While technically not required by the YAML specification to quote
forward slashes, when the behavior of paths is inconsistent it
makes it difficult to portably write FileCheck lines that will
work with either kind of path.
Differential Revision: https://reviews.llvm.org/D53169
llvm-svn: 344359
This reverts commit b86c16ad8c97dadc1f529da72a5bb74e9eaed344.
This is being reverted because I forgot to write a useful
commit message, so I'm going to resubmit it with an actual
commit message.
llvm-svn: 344358
Android uses a compressed relocation format, which means the size of the
relocation section isn't predictable based on the number of relocations,
and can vary if the layout changes in any way. To deal with this, the
linker normally runs multiple passes until the layout converges.
The layout should converge if the size of the compressed
relocation section increases monotonically: if the size of an encoded
offset increases by one byte, the larget value which can be encoded is
multiplied by 128, so the representable offsets grow much faster than
the size of the section itself.
The problem here is that there is no code to ensure the size of the
section doesn't decrease. If the size of the relocation section
decreases, the relative offsets can increase due to alignment
restrictions, so that can force the size of the relocation section to
increase again. The end result is an infinite loop; the loop gets cut
off after 10 iterations with the message "thunk creation not
converged".
To avoid this issue, this patch adds padding to the end of the
relocation section if its size would decrease. The extra
padding is harmless because of the way the format is defined:
decoding stops after it reaches the number of relocations specified
in the section's header.
Differential Revision: https://reviews.llvm.org/D53003
llvm-svn: 344300
When these are accessed with load/store instructions on ARM64,
it becomes strictly necessary to have them properly aligned.
This fixes PR39228.
Differential Revision: https://reviews.llvm.org/D53128
llvm-svn: 344264
This is https://bugs.llvm.org/show_bug.cgi?id=37538,
Currently, LLD may set both sh_link and sh_info for
.rela.plt section to zero when we have only .rela.iplt section part used.
ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)
says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table
and sh_info the "section to which the relocation applies."
When we set the sh_link field, for the regular case we use the .dynsym index.
For .rela.iplt sections, it is unclear what is the associated symbol table,
because R_*_RELATIVE relocations do not use symbol names and we might have no
.dynsym section at all so this patch uses .symtab section index.
Differential revision: https://reviews.llvm.org/D52830
llvm-svn: 344226
Summary:
Add a condition UnresolvedPolicy::Ignore to elf::warnUnorderedSymbol to suppress Sym->isUndefined() warnings from both
1) --symbol-ordering-file=
2) .llvm.call-graph-profile
If --unresolved-symbols=ignore-all is used,
no "undefined symbol" error/warning is emitted. It makes sense to not warn unorderable symbols.
Otherwise,
If an executable is linked, the default policy UnresolvedPolicy::ErrorOrWarn will issue a "undefined symbol" error. The unorderable symbol warning is redundant.
If a shared object is linked, it is possible that only part of object files are used and some symbols are left undefined. The warning is not very necessary.
In particular for .llvm.call-graph-profile, when linking a shared object, a call graph profile may contain undefined symbols. This case generated a warning before but it will be suppressed by this patch.
Reviewers: ruiu, davidxl, espindola
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53044
llvm-svn: 344195
This allows using #pragma comment(lib, "foo") in MinGW built code,
if built with -fms-extensions. (This works for system libraries and
static libraries only, as it doesn't try to look for .dll.a. As
ld.bfd doesn't support embedded defaultlib directives, this isn't
in widespread use among mingw users.)
Differential Revision: https://reviews.llvm.org/D53017
llvm-svn: 344124
Heejin Ahn