The main thing that they can't have is relocations that require the
creation of gots or plt. For now also accept R_PC.
Found while linking seabios.
llvm-svn: 295102
If we had SHT_GROUP sections, then when -r was used we might crash.
This is PR31952.
Issue happened because we emited relocation section though its target was discared
because was a member of duplicated group. When we tried to get VA of target,
segfault happened.
Core cause is the bug that GNU as 2.27 (and probably later versions) has.
In compare with llvm-mc, it does not include relocation sections into the group,
like shown in testcase. This patch covers that case.
Differential revision: https://reviews.llvm.org/D29929
llvm-svn: 295067
Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.
The same we did earlier for PC ones,
currenly LLD fails to link linux kernel,
reporting relocation out of range because of this.
Differential revision: https://reviews.llvm.org/D29714
llvm-svn: 295052
Unfortunately some consumers of our .o files produced with -r expect
only one section symbol per section. That is true of at least of go's
own linker.
Combining them is a somewhat convoluted process. We have to create a
symbol for every section since we don't know which ones will be
needed. The relocation sections also have to be written first to
handle the Elf_Rel addend.
I did consider a completely different approach:
We could remove the -r special case of relocation sections when
reading. We would instead have a copyRelocs function that is used
instead of scanRelocs. It would create a DynamicReloc for each
relocation and a RelocationSection for each input relocation section.
A complication of such change is that DynamicReloc would have to take
a section index and a input section instead of a symbol since with
-emit-relocs some DynamicReloc would hold relocations referring to the
dynamic symbol table and other to the static symbol table.
That would be a pretty big change, and if we do it it is probably
better to do it as a refactoring.
llvm-svn: 294816
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
Much of the code in PltSection and IPltSection is similar, we identify
the IPlt by a HeaderSize of 0 and alter our behaviour in the member
functions appropriately:
-Iplt does not have a header
-Iplt always follows after the Plt
Differential Revision: https://reviews.llvm.org/D29664
llvm-svn: 294579
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.
Differential Revision: https://reviews.llvm.org/D29637
llvm-svn: 294577
with temporarily file name fix in testcase.
Original commit message:
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294469
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294464
OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)
We did not support that, because got 3 lexer tokens here after recent changes.
This trivial patch fixes the issue, now whole expression inside
OUTPUT_ARCH is just ignored.
Differential revision: https://reviews.llvm.org/D29640
llvm-svn: 294432
LLD already parses ALIGN expression to specifiy alignment for output
sections in linker scripts but it never applies the alignment to the
output section. This change handles that.
Differential Revision: https://reviews.llvm.org/D29689
llvm-svn: 294374
DefinedSynthetic symbols are attached to sections,
for the case when such symbol was attached to non-allocated section,
we calculated its value incorrectly.
We subtracted Body->Section->Addr, but non-allocatable sections
should have zero VA in output and therefore result value was wrong.
And at the same time we have Body->Section->Addr != 0 for them
internally because use it for calculation of section size.
Patch fixes calculation of such symbols values.
Differential revision: https://reviews.llvm.org/D29653
llvm-svn: 294322
We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.
Differential revision: https://reviews.llvm.org/D29582
llvm-svn: 294290
Previously we did not do that. For example, for R_386_PC8,
0xFF addend was not treated as 0xFFFFFFFF(-1),
but was 0x000000FF.
Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation
overflow as a result.
Differential revision: https://reviews.llvm.org/D29490
llvm-svn: 294289
If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.
llvm-svn: 294253
We now create a dummy section with index 1 before processing the
linker script.
Thanks to George Rimar for finding the bug and providing the initial
testcase.
llvm-svn: 294252
This is a fix for Bugzilla 31813.
The problem is that the tokenizer does not create a separate token for
":" unless there's white space before it. Changed it to always create
a token for ":" and reworked some logic that relied on ":" being
attached to some tokens like "global:" and "local:".
llvm-svn: 294006
With a synthetic merge section we can have, for example, a single
.rodata section with stings, fixed sized constants and non merge
constants.
I can be simplified further by not setting Entsize, but that is
probably better done is a followup patch.
This should allow some cleanup in the linker script code now that
every output section command maps to just one output section.
llvm-svn: 294005
Summary: llvm/CodeGen/CommandFlags.h a utility function InitTargetOptionsFromCodeGenFlags which is used to set target options from flags based on the command line. The command line flags are stored in globals defined in the same file, and including the file in multiple places causes the globals to be defined multiple times, leading to linker errors. This change adds a single place in lld where these globals are defined and exports only the utility function. This makes it possible to call InitTargetOptionsFromCodeGenFlags from multiple places in lld, which a follow-up change will do.
Reviewers: davide, ruiu
Reviewed By: davide, ruiu
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D29058
llvm-svn: 293965
Instead of creating multiple PHDRs in a single loop, this patch
runs one for loop for each PHDR type. I think this improves code
readability.
llvm-svn: 293832
There could be multiple discontiguous output .note sections in which
case we need to put these into separate PT_NOTE segments rather then
placing them into a single segment. Where possible, we could reorder
the input sections to make sure that all .note are layed out next to
each other to avoid creation multiple PT_NOTE segments, but even in
that case, it's still possible to construct a discontiguous case e.g.
by using a linker script.
Differential Revision: https://reviews.llvm.org/D29364
llvm-svn: 293811
This is a fix for Bugzilla 28579.
The problem is that in --reproduce links the file path in -o option is
copied verbatim. When "lld @response.txt" link is run against the
extracted test case, if -o contains anything other that a plain file
name, the link will likely fail because the target directory in -o may
not exists. Stripping the directory path will create the output file
in the top level test directory.
Patch by Dmitry Mikulin!
llvm-svn: 293792
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.
Differential revision: https://reviews.llvm.org/D29327
llvm-svn: 293757
This is alternative to D28857 which was incorrect.
One of linux scripts contains:
vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.
And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol
This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).
Differential revision: https://reviews.llvm.org/D29332
llvm-svn: 293748
Previously, we were printing out something like this for
sections/symbols with alignment 16
0000000000201000 0000000000000182 10 .data
which I think confusing. I think printing it in decimal is better.
Differential Revision: https://reviews.llvm.org/D29258
llvm-svn: 293685
It is not clear what we should do when overflow occurs for these
relocations because the relocations are not an official part of
the i386 psABI. But checking for overflow is generally a good to do
and is consistent with other relocations such as R_X86_64_8.
llvm-svn: 293683
Our reporting for that case was just like:
ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23)
It did not give any information about error location.
Patch adds filename to error.
Differential revision: https://reviews.llvm.org/D29282
llvm-svn: 293640
Linux kernel linkerscript contains additional semicolon (last line):
.apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
__apicdrivers = .;
*(.apicdrivers);
I checked that both gold and bfd are able to parse something like:
.text : { ;;*(.text);;S = 0;; } }
Patch do the same.
Differential revision: https://reviews.llvm.org/D29276
llvm-svn: 293612
If no bss sections appear after the relro segment, the loader will round
the r/w segment size to the target's page size. Align the relro size in the
same way to ensure that it does not extend past the end of the program's
own memory region.
Differential Revision: https://reviews.llvm.org/D29242
llvm-svn: 293519
The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start
refer to positions in the file and are therefore not absolute. Making
them absolute was on unfortunate cargo cult of what bfd was doing.
Changing the symbols allows for pc relocations to them to be resolved,
which should fix the wine build.
llvm-svn: 293385
[ELF] Fixed formatting. NFC
and
[ELF] Bypass section type check
Differential revision: https://reviews.llvm.org/D28761
They do the opposite of what was asked for in the code review.
llvm-svn: 293320
Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.
The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.
llvm-svn: 293290
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
llvm-svn: 293283
It now uses the same infrastructure as symbol versions. This fixes us
creating a dynamic relocation without a corresponding dynamic symbol.
This also means that unlike gold and bfd we keep a STB_LOCAL in the
static symbol table. It seems an odd feature to offer precise control
over what is in a symbol table that is not used by the dynamic
linker. We can bring this back if needed, but it would probably be
better to just have --discard option that tells the linker to keep in
the static symbol table only what is in the dynamic one.
Should fix the eog build.
llvm-svn: 293093
Mapping symbols allow a mapping symbol aware disassembler to
correctly disassemble the PLT when the code immediately prior to the
PLT is Thumb.
To implement this we add a function to add symbols with local
binding to be defined in SyntheticSymbols.
Differential Revision: https://reviews.llvm.org/D28956
llvm-svn: 293044
Next code crashed under MSVS2015 for me:
this->OutSec->Info = this->Info = 1 + It - Symbols.begin();
Because It was end() and addition of 1 is not allowed.
vector implementation catched and failed that inside:
_Myiter& operator+=(difference_type _Off)
{ // increment by integer
#if _ITERATOR_DEBUG_LEVEL == 2
if (this->_Getcont() == 0
|| this->_Ptr + _Off < ((_Myvec *)this->_Getcont())->_Myfirst
|| ((_Myvec *)this->_Getcont())->_Mylast < this->_Ptr + _Off)
{ // report error
_DEBUG_ERROR("vector iterator + offset out of range");
_SCL_SECURE_OUT_OF_RANGE;
llvm-svn: 292940
The sh_info field of the SHT_SYMTAB section holds the index for the
first non-local symbol. When there are global symbols that are output
with STB_LOCAL binding due to having hidden visibility or matching
the local version from a version script, the calculated value of
NumLocals + 1 does not account for them. This change accounts for
global symbols being output with local binding.
Differential Revision: https://reviews.llvm.org/D28950
llvm-svn: 292910
Currently ld.lld -r allocates space for common symbols, whereas ld.bfd
-r doesn't. As a result the OpenBSD makefile bits for creating libraries
fail as they use ld -X -r to strip local symbols, which results in
duplicate symbol errors because space for the common symbols has been
allocated.
The diff also implements the --define-commons option such that allocation
of commons can be forced even if -r is used.
Patch by Mark Kettenis.
llvm-svn: 292878
As specified here:
* https://sourceware.org/binutils/docs/ld/MEMORY.html#MEMORY
There are two deviations from what is specified for GNU ld:
1. Only integer constants and *not* constant expressions
are allowed in `LENGTH` and `ORIGIN` initializations.
2. The `I` and `L` attributes are *not* implemented.
With (1) there is currently no easy way to evaluate integer
only constant expressions. This can be enhanced in the
future.
With (2) it isn't clear how these flags map to the `SHF_*`
flags or if they even make sense for an ELF linker.
Differential Revision: https://reviews.llvm.org/D28911
llvm-svn: 292875
Previously we stored kept locals in a KeptLocalSyms arrays,
belonged to files.
Patch makes SymbolTableSection to store locals in Symbols member,
that already present and was used for globals.
SymbolTableSection already had NumLocals counter member, so change
itself is trivial.
That allows to simplify handling of -r,
Body::DynsymIndex is no more used as "symbol table index" for relocatable
output.
Change was suggested during review of D28773 and opens road for D28612.
Differential revision: https://reviews.llvm.org/D29021
llvm-svn: 292789
Found that during attempts of linking linux kernel,
previously we partially duplicated code from getOutputSection(),
and it missed commons symbol case.
Differential revision: https://reviews.llvm.org/D28903
llvm-svn: 292594
If two sections contained relocations to absolute symbols with the same
value we would crash when trying to access their sections. Add a check that
both symbols point to sections before accessing their sections, and treat
absolute symbols as equal if their values are equal.
Differential Revision: https://reviews.llvm.org/D28935
llvm-svn: 292578
The freebsd sbrk implementation uses _end to find the initial value of
brk, so it has to be defined in the main binary.
This should fix the emacs build.
llvm-svn: 292512
A necessary first step towards range extension thunks is to delay
the creation of thunks until the layout of InputSections within
OutputSections has been done.
The change scans the relocations directly from InputSections rather
than looking in the ELF File the InputSection came from. This will
allow a future change to redirect the relocations to symbols defined
by Thunks rather than indirect when resolving relocations.
A side-effect of moving ThunkCreation is that the OutSecOff of
InputSections may change in an OutputSection that contains Thunks.
In well behaved programs thunks are not in OutputSections with
dynamic relocations.
Differential Revision: https://reviews.llvm.org/D28811
llvm-svn: 292359
This patch adds a test for an invalid output path for -Map option,
though that test is not for verifying that we are using error()
instead of fatal() in writeMapFile.
llvm-svn: 292336
Although this relocation type is not part of the x86-64 psABI, I intend to
use it internally as part of the ThinLTO implementation.
Differential Revision: https://reviews.llvm.org/D28841
llvm-svn: 292330
Patch changes behavior to not try open the output
file if we already know about error.
That is not just cleaner, but also fixes nasty behavior of linker that
could create huge temporarily files under certain conditions.
Differential revision: https://reviews.llvm.org/D28107
llvm-svn: 292219
On MIPS .got section cannot be included into the PT_GNU_RELRO segment.
Sometimes it might work, but in general it is unsupported. One of the
problem is that all sections marked by SHF_MIPS_GPREL should be grouped
together because data in these sections is addressable with a gp
relative address, but such sections might be writable.
This patch exclude mips .got from PT_GNU_RELRO segment and group
SHF_MIPS_GPREL sections.
llvm-svn: 292161
LLD exports symbols that are also present in used shared libraries to
make sure they are preempted at runtime. That is a reasonable default,
but we must allow for it to be overwritten with linker script. If we
don't, libraries that expect to be able to hide a c++ delete operator
will fail.
This should fix the firebird build.
llvm-svn: 292146
I had a error in map-file.s testcase under MSVS2015/win32:
map-file.s:30:16: error: expected string not found in input
// CHECK-NEXT: 0000000000200158 0000000000000030 8 .eh_frame
<stdin>:2:1: note: scanning from here
0000000000200158 10 30 .eh_frame
Format string '%0*x' requires an argument of type 'unsigned int',
but argument has type 'uint64_t'. Proper format is '%0*llx' then.
This fixes testcase failture for me.
llvm-svn: 292102
Previous code had a bug that if the program exits with an assert() or
fail() before the control reaches end of writeMapFile(), it leaves a
temporary file, because FileRemover's dtor isn't called in that case.
I could fix that by removeFileOnSignal() and other functions, but
I think we can simply write to the result file directly. I think
that is straightforward and easy to understand.
Additionally, that allows something like `-Map /dev/null` or a bash
hack such as `-Map >(grep symbol-im-looking-for)`. Previously,
that kind of things didn't work.
Differential Revision: https://reviews.llvm.org/D28714
llvm-svn: 292041
The freebsd dynamic linker doesn't check if the value is null (and it
is reasonable for it to do that). That means that producing a .so with
a null DT_INIT/DT_FINI causes the base address to be called.
This should fix the libreoffice build.
llvm-svn: 291944
These were 3 last synthetics that were added in addPredefinedSections() instead
of createSyntheticSections(). Now it is possible to move addition to correct common place.
Also patch fixes testcase which discards .shstrtab, by restricting doing that.
Differential revision: https://reviews.llvm.org/D28561
llvm-svn: 291908
The effect is that the nobits section gets space allocated on disk.
Both bfd and gold allow this with linker scripts. To try to keep
things simple in lld, always allow it for now.
llvm-svn: 291795
Previously we just crashed when had user defined
section .shstrtab, for example. Which name equals to synthetic one,
but have different type.
Testcase reveals an issue.
Differential revision: https://reviews.llvm.org/D28559
llvm-svn: 291765
Intention of change is to get rid of code duplication.
Decompressor was introduced in D28105.
Change allows to get rid of few methods relative to decompression.
Differential revision: https://reviews.llvm.org/D28106
llvm-svn: 291758
The same we did for x86 earlier:
list supported relocations explicitly and error out on unknown.
Differential revision: https://reviews.llvm.org/D28564
llvm-svn: 291751
We had an error when met this relocation
after latest changes aboult listing
x86 relocations explicitly.
Since we support R_X86_64_NONE,
and GNU ld supports R_386_NONE,
it seems reasonable to have.
Differential revision: https://reviews.llvm.org/D28552
llvm-svn: 291672
Previously some value was returned by default for relocations by getRelExpr(),
even if relocation actually was not supported.
This is orthogonal alternative to D28094.
Instead of implementing probably useless R_386_PC8/R_386_8 relocations,
this patch uses them in a testcase to demonstrate what happens
when LLD mets unsupported relocations.
Patch passes all testcases and changes logic only for x86.
Differential revision: https://reviews.llvm.org/D28516
llvm-svn: 291658
This actually simplifies the code a bit as now all local symbols are
handled uniformly.
This should fix the build of www/webkit2-gtk3.
llvm-svn: 291569
When reserving copy relocation space for a shared symbol, scan the DSO's
program headers to see if the symbol is in a read-only segment. If so,
reserve space for that symbol in a new synthetic section named .bss.rel.ro
which will be covered by the relro program header.
This fixes the security issue disclosed on the binutils mailing list at:
https://sourceware.org/ml/libc-alpha/2016-12/msg00914.html
Differential Revision: https://reviews.llvm.org/D28272
llvm-svn: 291524
This is in preparation for my next change, which will introduce a relro
nobits section. That requires that relro sections appear at the end of the
progbits part of the r/w segment so that the relro nobits section can appear
contiguously.
Because of the amount of churn required in the test suite, I'm making this
change separately.
llvm-svn: 291523
This patch enables something like "-o /dev/null".
Previouly, it failed because such files cannot be renamed.
Differential Revision: https://reviews.llvm.org/D28010
llvm-svn: 291496
The linkonce feature is a sort of proto-comdat. As far as I am aware no
compiler produces linkonce sections anymore, but some glibc i386 object
files contain definitions of symbol "__x86.get_pc_thunk.bx" in linkonce
sections. Drop those sections to avoid duplicate symbol errors.
This is glibc PR20543, we should remove this hack once that has been
fixed for a while.
Fixes PR31215.
Differential Revision: https://reviews.llvm.org/D28430
llvm-svn: 291474
This patch allows for linker scripts to assign a new value
to a symbol that is already defined (either in an object file
or the linker script itself).
llvm-svn: 291459
Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.
llvm-svn: 291413
Previously, when we printed out a path obtained from DWARF debug info,
we replaced \ with / on Windows. But that doesn't make sense. We should
respect the system's path separator.
llvm-svn: 291219
This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.
Differential Revision: https://reviews.llvm.org/D28103
llvm-svn: 291210
After Mark's patch I was wondering what was the rationale for the ELF
spec requiring us to merge only sections with matching flags and
types. I tried emailing
https://groups.google.com/forum/#!forum/generic-abi, but looks like my
emails are not being posted (the list is probably moderated). I
emailed Cary Coutant instead.
Cary pointed out that the section was a late addition and didn't got
the scrutiny it deserved. Given that and the problems found by
implementing the letter of the standard, I propose changing lld to
merge all sections with the same name and issue errors if the types or
some critical flags are different.
This should allow an unmodified firefox linked with lld to run.
This also merges some code with the linkerscript path.
llvm-svn: 291107
The glibc dynamic loader rounds the size down, so without this the loader
will fail to change the memory protection for the last page.
Differential Revision: https://reviews.llvm.org/D28267
llvm-svn: 290986
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.
llvm-svn: 290951
This is last known noticable fatal() in target.cpp.
We also have other ones for unknown relocations or
creating unknown targets, but that one can be just error I think.
Used yaml2obj to generate test.
Differential revision: https://reviews.llvm.org/D28049
llvm-svn: 290335
Vectors returned form that function contained nullptrs or Undefined symbols.
This patch filter them out. This makes use of the function a bit easier.
llvm-svn: 290334
Previously, that was an alias to -color-diagnostics=auto. However,
Clang's -fcolor-diagnostics is an alias to -fcolor-diagnostics=always,
so that was confusing. This patch fixes that issue.
llvm-svn: 290332
Previously, you had to call initDemangledSyms() before accessing DemangledSyms.
Now getDemangledSyms() initializes it and then returns it. So it is now less easy
to use it in a wrong way.
llvm-svn: 290323
DefinedSynthetic is not created for a real ELF object, so it doesn't
have to be a template function. It has a virtual st_value, which is
either 32 bit or 64 bit, but we can simply use 64 bit.
llvm-svn: 290241
We probably would want to avoid fatal() if we can in context of librarification,
but for me reason of that patch is to help D27900 go.
D27900 changes errors reporting to something like
error: text1
note: text2
note: text3
where hint used to provide additional information about location. In that case
I can't just call fatal() because user will not see notes after that what adds additional complication to handle.
So It is good to switch fatal() to error() where it is possible.
Also it adds testcase with broken relocation number.
Previously we did not have any, It checks that error() instead of fatal() works fine.
Differential revision: https://reviews.llvm.org/D27973
llvm-svn: 290239
It was revealed by D27831.
If we have linkerscript that includes another one that sets OUTPUT for example:
RUN: echo "INCLUDE \"foo.script\"" > %t.script
RUN: echo "OUTPUT(\"%t.out\")" > %T/foo.script
then we do:
void ScriptParser::readInclude() {
...
std::unique_ptr<MemoryBuffer> &MB = *MBOrErr;
tokenize(MB->getMemBufferRef());
OwningMBs.push_back(std::move(MB));
}
void ScriptParser::readOutput() {
...
Config->OutputFile = unquote(Tok);
...
}
Problem is that OwningMBs are destroyed after script parser do its job.
So all Toks are dead and Config->OutputFile points to destroyed data.
Patch suggests to save all included scripts into using string Saver.
Differential revision: https://reviews.llvm.org/D27987
llvm-svn: 290238
Older versions of BFD generate libraries with .MIPS.abiflags that only
concatenate the individual .MIPS.abiflags sections instead of merging.
Patch by Alexander Richardson.
Differential revision: https://reviews.llvm.org/D27770
llvm-svn: 290237
GlobPattern is a class to handle glob pattern matching. Currently
only LLD is using that, but technically that feature is not specific
to linkers, so in this patch I move that file to LLVM.
Differential Revision: https://reviews.llvm.org/D27969
llvm-svn: 290212
That was requested by Mark Kettenis in llvm-dev:
"It is the intention that .openbsd.randomdata sections are made
read-only after initialization. The native (ld.bfd based) OpenBSD
toolchain accomplishes this by including .openbsd.randomdata into the
PT_GNU_RELRO segment."
He suggested code change, I added testcase.
Differential revision: https://reviews.llvm.org/D27974
llvm-svn: 290174
Previously, some errors that were checked before we set to
Config->ColorDiagnostics weren't colored. This patch moves the code
to set the variable so that such error messages are colored just like
other error messages.
llvm-svn: 290157
That variable was of type DenseMap<StringRef, unsigned>, but the
unsigned numbers needed to be monotonicly increasing numbers because
the implementation that used the variable depended on that fact.
That was an implementation detail and shouldn't have leaked into Config.
This patch simplifies its type to std::vector<StringRef>.
llvm-svn: 290151
This handles all the corner cases if setting a section address:
- If the address is too low, we cannot allocate the program headers.
- If the load address is lowered, we have to do that before finalize
This also shares some code with the linker script since it was already
hitting similar cases.
This is used by the freebsd boot loader. It is not clear if we need to
support this with a non binary output, but it is not as bad as I was
expecting.
llvm-svn: 290136
--retain-symbols-file=filename
Retain only the symbols listed in the file filename, discarding all others.
filename is simply a flat file, with one symbol name per line. This option
is especially useful in environments (such as VxWorks) where a large global
symbol table is accumulated gradually, to conserve run-time memory.
Note: though documentation says "--retain-symbols-file does not discard
undefined symbols, or symbols needed for relocations.", both bfd and gold
do that, and this patch too, like testcase show.
Differential revision: https://reviews.llvm.org/D27716
llvm-svn: 290122
AArch64 TLSDESC for local symbol in shared objects are implemented in a
arch specific manner where the TLSDESC dynamic relocation addend is the
symbol VM inside the TLS block. For instance, with a shared library
created from the code:
--
static __thread int32_t x1;
static __thread int64_t x2;
int32_t foo1 (int32_t x)
{
x1 += x;
return x;
}
int64_t foo2 (int64_t x)
{
x2 += x;
return x;
}
--
The dynamic relocation should be create as:
Relocations [
Section (N) .rela.dyn {
<Address1> R_AARCH64_TLSDESC - 0x0
<Address2> R_AARCH64_TLSDESC - 0x8
}
]
Where 0x0 addend in first dynamic relocation is the address of 'x1'
in TLS block and '0x8' is the address of 'x2'.
Checked against test-suite on aarch64-linux-gnu.
llvm-svn: 290099
Use of CachedHashStringRef makes sense only when we reuse hash values.
Sprinkling it to all DenseMap has no benefits and just complicates data types.
Basically we shouldn't use CachedHashStringRef unless there is a strong
reason to to do so.
llvm-svn: 290076
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
llvm-svn: 290062
It os used in work/emulators/qemu-user-static port.
Which tries to use -Ttext-segment and then:
# In case ld does not support -Ttext-segment, edit the default linker
# script via sed to set the .text start addr. This is needed on FreeBSD
# at least.
<here it calls -verbose to extract and edit default bfd linker script.>
Actually now we are do not fully support -Ttext properly (see D27613),
but we also seems never will provide anything close to default script, like bfd do,
so at least this patch introduces proper alias handling.
llvm-svn: 289827
Patch continues work started in D24706 and D25821.
in this patch symbol table and constant pool areas were
added to .gdb_index section output.
This one finishes the implementation of --gdb-index functionality in LLD.
Differential revision: https://reviews.llvm.org/D26283
llvm-svn: 289810
Patch continues work started in D24706,
in this patch address area was added to .gdb_index section output.
Differential revision: https://reviews.llvm.org/D25821
llvm-svn: 289790
PR31335 shows that we do that in next case:
SECTIONS { .text 0x2000 : {. = 0x100 ; *(.text) } }
though documentations says that "If . is used inside a section
description however, it refers to the byte offset from the start
of that section, not an absolute address. " looks does not work
as documented in bfd (as mentioned in comments for PR31335).
Until we find out the expected behavior was suggested at least not
to 'crash', what we do after trying to generate huge file.
Differential revision: https://reviews.llvm.org/D27712
llvm-svn: 289782
Rafael Espindola