It was raised during the review of D43819.
LLD usually use [X, Y] for reporting ranges, like below:
"relocation R_386_16 out of range: 65536 is not in [0, 65535]"
Patch changes rangeToString() to do the same.
Differential revision: https://reviews.llvm.org/D44207
llvm-svn: 326918
Summary:
I originally tried to simplify code and then noticed that lld doesn't
do what it tells to the user by warn(). It says "unable to order
discarded symbol" but it actually can for sections eliminated by ICF.
With this patch, lld doesn't sort such sections.
Reviewers: jhenderson, rafael
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D44180
llvm-svn: 326911
LLD uses the debug info and debug line sections to determine the location of
e.g. references to undefined symbols, when producing error messages. In the
event that debug info was present, but debug line parsing failed for some
reason, then a nullptr would end up being dereferenced by the location-lookup
code.
Differential Revision: https://reviews.llvm.org/D44205
Reviewers: grimar
llvm-svn: 326899
With fix: add missing "RUN:" prefix to test case.
Original commit message:
We do not report LMA region overflows currently.
Both GNU linkers do that. The patch implements it.
Differential revision: https://reviews.llvm.org/D44094
llvm-svn: 326895
We do not report LMA region overflows currently.
Both GNU linkers do that. The patch implements it.
Differential revision: https://reviews.llvm.org/D44094
llvm-svn: 326892
Currently, LLD segfaults when linker script attempts to discard
one of the hash sections. This patch fixes that.
Differential revision: https://reviews.llvm.org/D44012
llvm-svn: 326891
It looks like the problem that caused us to originally warn instead of
error was that of a symbol being assigned to the same version twice.
Now we don't warn if a symbol is assigned to the same version twice,
but error if it is assigned to multiple.
This fixes pr28342.
llvm-svn: 326813
We do not expand memory region correctly for following scripts:
.foo.1 :
{
*(.foo.1)
. += 0x1000;
} > ram
Patch generalizes expanding of output sections and memory
regions in one place and fixes the issue.
Differential revision: https://reviews.llvm.org/D43999
llvm-svn: 326688
"division by zero" or "modulo by zero" are not
very informative errors and even probably confusing
as does not let to know that error is coming from linker script.
Patch adds location reporting.
Differential revision: https://reviews.llvm.org/D43934
llvm-svn: 326686
LLD can not catch a memory area overflow when using a data command.
If we have the script below:
.foo :
{
*(.foo)
BYTE(0x1)
} > ram
where BYTE overflows the ram region, we do not report it currently.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D43948
llvm-svn: 326545
GNU linkers by convention supports both `--foo bar` and `--foo=bar` styles
for all long options that take arguments.
Differential Revision: https://reviews.llvm.org/D43972
llvm-svn: 326506
Summary:
If an executable needs text relocations, it should be marked as such so
that the loader can prepare for text relocations. We currently create a
dummy segment with DT_TEXTREL for that purpose.
Generic ABI as of 2000 [1] mentioned that "Its [DT_TEXTREL's] use
has been superseded by the DF_TEXTREL flag". However, it's actually not
superseded even after 18 years. OpenBSD and musl recognize only DT_TEXTREL.
So we still need to set both.
[1] http://www.sco.com/developers/gabi/2000-07-17/ch5.dynamic.html
Reviewers: rafael
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D43920
llvm-svn: 326503
With the current code if the script has a PHDRS we always obey and try
to allocate a header. This can cause Min - HeaderSize to underflow.
It looks like bfd actually prints an error for this case. With this
patch we do the same.
Found while looking at pr36515.
llvm-svn: 326441
LLD crashes with broken scripts shown in testcase,
because fails to read memory regon name and accesses
MemoryRegions's element which is nullptr.
Patch fixes it.
Differential revision: https://reviews.llvm.org/D43866
llvm-svn: 326431
This is PR36515.
Currenly if we have a script like .debug_info 0 : { *(.debug_info) },
we would not remove this section and keep it in the output.
That does not work, because it is common case for
debug sections to have a zero address expression.
Patch changes behavior so that we remove only sections
that do not use symbols in its expressions.
Differential revision: https://reviews.llvm.org/D43863
llvm-svn: 326430
Previously, we didn't try to make effort to put .note sections next
to each other in the output file, so two .note sections were likely
to be stored to two separate NOTE segments. That's undesirable because
we should create as few segments as possible in general.
Differential Revision: https://reviews.llvm.org/D43858
llvm-svn: 326410
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
We should process symbols inside output section declarations the same way as top-level ones.
Differential Revision: https://reviews.llvm.org/D43008
llvm-svn: 326305
Imagine that we have sections A, B, C, where A == C and
symbol ordering file containing symbols: symC, symB, symA
Previously because of ICF it was possible that final order would be
B, A or B, C. That violates order specified in ordering file.
Patch changes that.
Differential revision: https://reviews.llvm.org/D43234
llvm-svn: 326179
It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.
Differential Revision: https://reviews.llvm.org/D43011
llvm-svn: 326176
This fixes pr36475.
I think this code can be simplified a bit, but I would like to check
in the more direct fix if we are in agreement on the direction and
then refactor.
This is not something that bfd does. The issue is not noticed in bfd
because it keeps fewer sections from the linkerscript in the output.
The reasons why it seems reasonable to do this:
- As George noticed, we would still keep the flags if the output
section had both an empty synthetic section and a regular section
- We need an heuristic to find the flags of output sections. Using the
flags of a synthetic section that would have been there seems a
reasonable heuristic.
llvm-svn: 326137
MIPS ABIs require that if an executable file uses non-PIC model, the
EI_ABIVERSION entry in the ELF header should be incremented from 0 to 1.
That allows obsoleted / limited dynamic linkers refuse to link them.
llvm-svn: 325890
This continues direction started in D43069.
We can keep sections that are explicitly assigned to segment in script.
It helps to simplify code.
Differential revision: https://reviews.llvm.org/D43571
llvm-svn: 325887
Latest patch version now.
Original commit message:
[ELF] - Do not crash with --emit-relocs and --icf=all together.
Previously we would crash because did not mark .rel[a] sections
as dead and they tried to access parent which was not live
after ICF and therefore was null.
Differential revision: https://reviews.llvm.org/D43241
llvm-svn: 325879
Previously we would crash because did not mark .rel[a] sections
as dead and they tried to access parent which was not live
after ICF and therefore was null.
Differential revision: https://reviews.llvm.org/D43241
llvm-svn: 325877
This is for fixing PR36297.
Issue itself is that if we have SECTIONS { .bar (a+b) : { *(.stub) } };
script and no section .stub, when LLD will remove .bar, but
produce output with undefined symbols a and b.
Differential revision: https://reviews.llvm.org/D43069
llvm-svn: 325875
We have an internal program that does't link without this patch. I don't
know of any open-source program that needs this, but there might be.
Since this patch improves compatibility with GNU linkers with a few lines
of code, I think it's worth to be committed.
The problem is about undefined symbols in DSOs. Some programs depend on
the GNU linkers' behavior that they pull out object files from archive
files to resolve undefined symbols in DSOs. We already allow that kind of
"reverse" dependency (from DSOs to the main executable) for regular
symbols, in particular, for "__progname" symbol (which is usually in
crt0.o), but that doesn't work if the symbol is in an archive file.
This patch is to make it work.
Differential Revision: https://reviews.llvm.org/D43658
llvm-svn: 325849
Rui Ueyama