Normally to find the offset of a value in a section, we have to
compute the value since the alignment is defined on the final address.
If the alignment is trivial, we can skip the value computation. This
allows us to know the offset even in cases where we cannot yet know
the value.
llvm-svn: 313777
We try to evaluate expressions early when possible, but it is not
possible to evaluate them early if they are based on a section.
Before we would get this wrong on ABSOLUTE expressions.
llvm-svn: 313764
Its a PR34648 which was a segfault that happened because
we stored pointers to elements in DenseMap.
When DenseMap grows such pointers are invalidated.
Solution implemented is to keep elements by pointer
and not by value.
Differential revision: https://reviews.llvm.org/D38034
llvm-svn: 313741
According to Microsoft's PE/COFF documentation, a SECREL relocation is
"The 32-bit offset of the target from the beginning of its section". By
my reading, the "from the beginning of its section" implies that the
offset is unsigned.
Change from an assertion to an error, since it's possible to trigger
this condition normally for input files with very large sections, and we
should fail gracefully for those instead of asserting.
Differential Revision: https://reviews.llvm.org/D38020
llvm-svn: 313703
Sections are limited to 4 GiB. Error out early if a section exceeds this
size, rather than overflowing the section size and getting confusing
assertion failures/segfaults later.
Differential Revision: https://reviews.llvm.org/D38005
llvm-svn: 313699
EhSectionPiece used to have a pointer to a section, but that pointer was
mostly redundant because we almost always know what the section is without
using that pointer. This patch removes the pointer from the struct.
This patch also use uint32_t/int32_t instead of size_t to represent
offsets that are hardly be larger than 4 GiB. At the moment, I think it is
OK even if we cannot handle .eh_frame sections larger than 4 GiB.
Differential Revision: https://reviews.llvm.org/D38012
llvm-svn: 313697
CieRecord is a struct containing a CIE and FDEs, but oftentimes the
struct itself is named `Cie` which caused some confusion. This patch
renames them `CieRecords` or `Rec`.
llvm-svn: 313681
Given a linker script that ends in
.some_sec { ...} ;
__stack_start = .;
. = . + 0x2000;
__stack_end = .;
lld would put orphan sections like .comment before __stack_end,
corrupting the intended meaning.
The reason we don't normally move orphans past assignments to . is to
avoid breaking
rx_sec : { *(rx_sec) }
. = ALIGN(0x1000);
/* The RW PT_LOAD starts here*/
but in this case, there is nothing after and it seems safer to put the
orphan section last. This seems to match bfd's behavior and is
convenient for writing linker scripts that care about the layout of
SHF_ALLOC sections, but not of any non SHF_ALLOC sections.
llvm-svn: 313646
This is PR34506.
Imagine we have 2 sections the same name but different COMDAT groups:
.section .foo,"axG",@progbits,bar,comdat
.section .foo,"axG",@progbits,zed,comdat
When linking relocatable we do not merge SHT_GROUP sections. But still would merge
both input sections .foo into single output section .foo.
As a result we will have 2 different SHT_GROUPs containing the same section, what
is wrong.
Patch fixes the issue, preventing merging SHF_GROUP sections with any others.
Differential revision: https://reviews.llvm.org/D37574
llvm-svn: 313621
We crashed when --emit-relocs was used
and relocated section was collected by GC.
Differential revision: https://reviews.llvm.org/D37561
llvm-svn: 313620
This patch removes lot of static Instances arrays from different input file
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.
It allows to iterate over input files in a non-templated code.
Differential revision: https://reviews.llvm.org/D35987
llvm-svn: 313619
EhSectionPiece inherited from SectionPiece, but we did not actually use
EhSectionPiece objects as SectionPiece ojbects. They were handled as
distinct types. So it didn't make much sense to use inheritance.
llvm-svn: 313587
"Repl" member is guranteed to have a non-null pointer. If an input
section is not merged by ICF, "Repl" points to "this". Otherwise, it
points to some other section. It must not be NULL.
llvm-svn: 313556
This is not really OK in C++11, and GCc triggers a warning.
We can switch back to default arguments when C++14 will be the
minimum version of the standard supported, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#974
Ack'ed by Rafael.
llvm-svn: 313550
Does not seem we need to set SectionIndex here.
It is set in finalizeSections() later.
Differential revision: https://reviews.llvm.org/D37815
llvm-svn: 313522
r303378 was submitted because r303374 (Merge IAT and ILT) made lld's
output incompatible with the Binding feature. Now that r303374 was
reverted, we do not need to keep this change.
Pointed out by pcc.
llvm-svn: 313414
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This fixes pr34301.
As the bug points out, we want to keep some relocations with undefined
weak symbols. This means that we cannot always claim that these
symbols are not preemptible as we do now.
Unfortunately, we cannot also just always claim that they are
preemptible. Doing so would, for example, cause us to try to create a
plt entry when we don't even have a dynamic symbol table.
What almost works is to say that weak undefined symbols are
preemptible if and only if we have a dynamic symbol table. Almost
because we don't want to fail the build trying to create a copy
relocation to a weak undefined.
llvm-svn: 313372
Patch removes one of OutputSectionFactory::addInputSec methods.
That allows to simplify reporting of discarded sections and
should help to D37561.
Differential revision: https://reviews.llvm.org/D37735
llvm-svn: 313361
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
_gp points to a position in the file, so it is not really absolute. It
is also simpler to not force it to be absolute, so if there is no
strong ABI requirement we should not do it.
llvm-svn: 313333
GNU ld manual says that multi-letter long option can be prefixed with
either -- or -. Therefore, we should accept not only --subsystem but
also -subsystem, for example.
There is one exception. If an option starts with "o", it should only be
prefixed with -- to avoid ambiguity with -o<filename> option.
Differential Revision: https://reviews.llvm.org/D37825
llvm-svn: 313286
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
Arg instances can be claimed. After claimed, its `isClaimed` function
returns true. We do not use that notion in lld, so using NoClaim
versions of functions is just confusing. This patch is to just use
hasArg instead of hasArgNoClaim.
llvm-svn: 313187
There are no alises handled by this switch, but getUnaliasesdOption is
preferred way of doing this. This is also consistent with ELF and COFF.
llvm-svn: 313180
This is how the flag is documented in GNU binutils ld; -Bstatic
only applies to -l options after it, until the next -Bdynamic.
Differential Revision: https://reviews.llvm.org/D37794
llvm-svn: 313175
In MinGW configurations (GCC, or clang with a *-windows-gnu target),
the -export directives in the object file contains the undecorated
symbol name, while it is decorated in MSVC configurations. (On the
command line, link.exe takes an undecorated symbol name for the
-export argument though.)
Differential Revision: https://reviews.llvm.org/D37772
llvm-svn: 313174
There is no need to scan over all input sections for relocatable output.
As we do not process or scan relocations anyways.
Patch moves check for Config->Relocatable out to avoid that and also removes
excessive check for isa<EhInputSection> from first for loop.
It is excessive because we handle all of them in a second for loop below.
That all allowed to simplify code.
Differential revision: https://reviews.llvm.org/D37746
llvm-svn: 313127
This should fix the lto bootstrap.
It is somewhat hard to remember about lazy symbols deep down in the
link. It might be worth it replacing them with undefined symbols once
we are done adding files.
llvm-svn: 313103
Rafael Espindola