Added checks to test that we do not produce
output where VA of sections overruns the address
space available.
Differential revision: https://reviews.llvm.org/D43820
llvm-svn: 329063
This fixes PR36927.
The issue is next. Imagine we have -Ttext 0x7c and code below.
.code16
.global _start
_start:
movb $_start+0x83,%ah
So we have R_386_8 relocation and _start at 0x7C.
Addend is 0x83 == 131. We will sign extend it to 0xffffffffffffff83.
Now, 0xffffffffffffff83 + 0x7c gives us 0xFFFFFFFFFFFFFFFF.
Techically 0x83 + 0x7c == 0xFF, we do not exceed 1 byte value, but
currently LLD errors out, because we use checkUInt<8>.
Let's try to use checkInt<8> now and the following code to see if it can help (no):
main.s:
.byte foo
input.s:
.globl foo
.hidden foo
foo = 0xff
Here, foo is 0xFF. And addend is 0x0. Final value is 0x00000000000000FF.
Again, it fits one byte well, but with checkInt<8>,
we would error out it, so we can't use it.
What we want to do is to check that the result fits 1 byte well.
Patch changes the check to checkIntUInt to fix the issue.
Differential revision: https://reviews.llvm.org/D45051
llvm-svn: 329061
Having 8/16 bits dynamic relocations is incorrect.
Both gold and bfd (built from latest sources) disallow
that too.
Differential revision: https://reviews.llvm.org/D45158
llvm-svn: 329059
The Plt relative relocations are R_PPC64_JMP_SLOT in the V2 abi, and we only
reserve 2 double words instead of 3 at the start of the array of PLT entries for
lazy linking.
Differential Revision: https://reviews.llvm.org/D44951
llvm-svn: 329006
Adds a simple test for accessing a local global variable in the ElfV2 abi.
Checks that the toc base used is the expected offset from the .TOC. symbol,
and that the offsets for the global are calculated relative to the toc base.
llvm-svn: 328982
It generally does not matter much where we place sections ordered
by --symbol-ordering-file relative to other sections. But if the
ordered sections are hot (which is the case already for some users
of --symbol-ordering-file, and is increasingly more likely to be
the case once profile-guided section layout lands) and the target
has limited-range branches, it is beneficial to place the ordered
sections in the middle of the output section in order to decrease
the likelihood that a range extension thunk will be required to call
a hot function from a cold function or vice versa.
That is what this patch does. After D44966 it reduces the size of
Chromium for Android's .text section by 60KB.
Differential Revision: https://reviews.llvm.org/D44969
llvm-svn: 328905
Now that we have the ability to create short thunks, it is beneficial
for thunk sections to be surrounded by ThunkSectionSpacing bytes
of code on both sides in order to increase the likelihood that the
distance from the thunk to the target will be sufficiently small to
allow for the creation of a short thunk. This is currently the case
for most thunks that we create, except for the last one, which could,
depending on the size of the output section, potentially appear near
the end and therefore have a relatively small amount of code after it.
This patch moves the last thunk section to ThunkSectionSpacing bytes
before the end of the output section, as long as the section is larger
than 2*ThunkSectionSpacing bytes. It reduces the size of Chromium
for Android's .text section by 32KB.
Differential Revision: https://reviews.llvm.org/D44966
llvm-svn: 328889
/FIXED:NO is always the default, so that part needs no work.
Also test the interaction of /ORDER: with /INCREMENTAL.
https://reviews.llvm.org/D45091
llvm-svn: 328877
As of rL215127, FileCheck has an -allow-empty flag,
so this could be used instead of writing a dummy line.
But it looks like the log is never empty now, so not
even that is needed.
llvm-svn: 328862
I tried a few different designs to find a way to implement it without
too much hassle and settled down with this. Unlike before, object files
given as arguments for --just-symbols are handled as object files, with
an exception that their section tables are handled as if they were all
null.
Differential Revision: https://reviews.llvm.org/D42025
llvm-svn: 328852
A short thunk uses a direct branch (b or b.w) instruction, and is used
when the target has the same thumbness as the thunk and is within
direct branch range (32MB for ARM, 16MB for Thumb-2). Reduces the
size of Chromium for Android's .text section by around 160KB.
Differential Revision: https://reviews.llvm.org/D44963
llvm-svn: 328846
There are two FPMs in an MSF file, the idea being that for
incremental updates you can write to the alternate one and then
atomically swap them on commit. LLVM defaulted to using FPM1
on the first commit, but this differs from Microsoft's behavior
which is to default to using FPM2 on the first commit. To
eliminate some byte-level file differences, this patch changes
LLVM's default to also be FPM2.
Additionally, LLVM was trying to be "smart" about marking FPM
pages allocated. In addition to marking every page belonging
to the alternate FPM as unallocated, LLVM also marked pages at
the end of the main FPM which were not needed as unallocated.
In order to match the behavior of Microsoft-generated PDBs, we
now always mark every FPM block as allocated, regardless of
whether it is in the main FPM or the alt FPM, and regardless of
whether or not it describes blocks which are actually in the file.
This has the side benefit of simplifying our code.
llvm-svn: 328812
The PLT retpoline support for X86 and X86_64 did not include the padding
when writing the header and entries. This issue was revealed when linker
scripts were used, as this disables the built-in behaviour of filling
the last page of executable segments with trap instructions. This
particular behaviour was hiding the missing padding.
Added retpoline tests with linker scripts.
Differential Revision: https://reviews.llvm.org/D44682
llvm-svn: 328777
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO
so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols
with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion
to do it is simpler.
llvm-svn: 328738
This enables callback-style programming where the JavaScript environment
can call back into the Wasm environment using a function pointer
received from the module.
Differential Revision: https://reviews.llvm.org/D44427
llvm-svn: 328643
Some tools (dwarfdump for example) get confused by the current -O0 -r
output since it has multiple copies of .debug_str.
We cannot just merge sections with the same name as they can have
different sh_entsize.
We could have duplicated logic for merging sections based on name and
sh_entsize, but it seems better to just use the existing logic by
enabling optimizations.
llvm-svn: 328640
The Data member of synthetic section's is not valid and empty. The Data
member is required to be valid by ICF as it is used by ICF to determine
the equality of section contents. Therefore, exclude synthetic sections
from ICF.
Fixes bug PR36910.
Differential Revision: https://reviews.llvm.org/D44923
llvm-svn: 328624
When the target saves ElfSym::GlobalOffsetTable in the .got rather than
.got.plt, Target->GotHeaderEntriesNum states the number of extra entries
required in the .got. Rather than having to add Target->GotHeaderEntriesNum to
NumEntries in every function which refers to NumEntries, this patch changes the
initial value of NumEntries in the constructor.
Differential Revision: https://reviews.llvm.org/D44744
llvm-svn: 328559
Currently, we might have a bug with scripts like below:
.foo : ALIGN(8)
{
*(.foo)
} > ram
because do not expand the memory region when doing ALIGN.
This might result in file range overlaps. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D44730
llvm-svn: 328479
Currently when we build input sections list in linker script
we ignore all rel[a] sections. That was done to support
scripts like .rela.dyn : { *(.rela.data) } for emit relocs.
Though as a result following scripts were also silently ignored:
/DISCARD/ : { *(.rela.plt)
/DISCARD/ : { *(.rela.dyn)
and we produced output with this sections. That is not ideal.
The solution this patch suggests is simple: do not ignore synthetic
rel[a] sections. That way we can enable common discarding logic
for them and report a proper error.
Differential revision: https://reviews.llvm.org/D41640
llvm-svn: 328419
This was reverted several times due to what ultimately turned out
to be incompatibilities in our serialized hash table format.
Several changes went in prior to this to fix those issues since
they were more fundamental and independent of supporting injected
sources, so now that those are fixed this change should hopefully
pass.
llvm-svn: 328363
When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.
But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.
This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.
Differential Revision: https://reviews.llvm.org/D44810
llvm-svn: 328348
When looking for the output section and the output offset the
expectation was that the caller had looked at Repl. That works fine
for InputSections, but in the case of MergeInputSections the caller
doesn't have the section that is actually replaced.
The original testcase was failing because getOutputSection was
returning null. The slightly extended testcase also checks that
getOffset also checks Repl.
I will send a refactoring separetelly.
llvm-svn: 328332
This fixes PR36367 which is about segfault when --emit-relocs is
used together with .eh_frame sections which happens because
of reordering of regular and .rel[a] sections.
Path changes loop that iterates over input sections to create
relocation target sections first.
Differential revision: https://reviews.llvm.org/D44679
llvm-svn: 328299
Currently lld just parses the .debug_line section assuming that there
is only one compile unit. That assumption is false (PR36793).
I have a patch that changes lld to iterate over the compile units and
parse the portions of the .debug_line they point to (which fixes
PR36793).
A problem is that we will then need a compiler unit pointing to
.debug_line for lld to see it.
It seems like bfd has the same restriction.
This patch updates existing tests to add a minimal compile unit so
that they still work with PR36793 fixed.
llvm-svn: 328215
The relocations R_PPC64_REL16_LO and R_PPC64_REL16_HA should return R_PC
for getRelExpr since they compute #lo(S + A – P) and #ha(S + A – P).
Differential Revision: https://reviews.llvm.org/D44648
llvm-svn: 328103
Patch teaches LLD to hint user about -fdebug-types-section flag
if relocation overflow happens in debug section.
Differential revision: https://reviews.llvm.org/D40954
llvm-svn: 328081
This is still failing on a different bot this time due to some
issue related to hashing absolute paths. Reverting until I can
figure it out.
llvm-svn: 328014
The issue causing this to fail in certain configurations
should be fixed.
It was due to the fact that DIA apparently expects there to be
a null string at ID 1 in the string table. I'm not sure why this
is important but it seems to make a difference, so set it.
llvm-svn: 328002
There are no reasons for them to be STV_DEFAULT,
recently bfd did the same change.
Differential revision: https://reviews.llvm.org/D44566
llvm-svn: 327983
It seems @LLVM_LIBXML2_ENABLED@ doesn't always get set to 0 when not available,
but to nothing, which broke parsing of lit.site.cfg.py.
> @LLVM_LIBXML2_ENABLED@ will be replaced with 0 or 1. Putting quotes
> around that is unnecessary and just makes it harder to use the value.
> This matches what have_zlib does below.
>
> This also puts the flag together with the feature-related ones instead
> of the path-related flags.
llvm-svn: 327966
Rafael Espindola