| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 292228
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 291602
|
|
|
|
|
|
|
| |
We were already dropping them from the dynamic symbol table, but the
regular symbol table was still listing them as globals.
llvm-svn: 291573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 289824
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
The VA of _gp was being truncated to 32 bits when calling getVa(), but
for 64bit MIPS we need to write a 64 bit value to .MIPS.options.
Patch by Alexander Richardson.
Differential revision: https://reviews.llvm.org/D27672
llvm-svn: 289432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The i386 glibc ld.so expects the .got.slot entry that is relocated by a
R_386_IRELATIVE relocation to point directly at the ifunc resolver and
not the address of the PLT entry + 6 (thus entering the lazy resolver).
This is also the case for ARM and I suspect it is because these use REL
relocations and can't use the addend field to store the address of the
ifunc resolver. If the lazy resolver is used we get an error message
stating that only R_386_JUMP_SLOT is supported.
As ARM and i386 share the same code, I've removed the ARM specific test
and added a writeIgotPlt() function that by default calls writeGotPlt().
ARM and i386 override this to write the address of the ifunc resolver.
Differential Revision: https://reviews.llvm.org/D27581
llvm-svn: 289198
|
|
|
|
| |
llvm-svn: 289084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces new synthetic sections IpltSection, IgotPltSection
that represent the ifunc entries that would previously have been put in
the PltSection and the GotPltSection. The separation makes sure that
the R_*_IRELATIVE relocations are placed after the non R_*_IRELATIVE
relocations, which permits ifunc resolvers to know that the .got.plt
slots will be initialized prior to the resolver being called.
A secondary benefit is that for ARM we can move the IgotPltSection and its
dynamic relocations to the .got and .rel.dyn as the ARM glibc expects all
the R_*_IRELATIVE relocations to be in the .rel.dyn
Differential revision: https://reviews.llvm.org/D27406
llvm-svn: 289045
|
|
|
|
|
|
|
|
| |
The presence of DT_DEBUG entry is unrelated to the existence of entry point.
Differential Revision: https://reviews.llvm.org/D27496
llvm-svn: 288877
|
|
|
|
| |
llvm-svn: 288599
|
|
|
|
|
|
|
|
|
|
|
| |
sections from linkerscript.
This change continues what was started by D27040
Now all allocatable synthetics should be available from script side.
Differential revision: https://reviews.llvm.org/D27131
llvm-svn: 288150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MipsGotSection::getPageEntryOffset calculates index of GOT entry
with a "page" address. Previously this method changes the state
of MipsGotSection because it modifies PageIndexMap field. That leads
to the unpredictable results if getPageEntryOffset called from multiple threads.
The patch makes getPageEntryOffset constant. To do so it calculates GOT
entry index but does not update PageIndexMap field. Later in the
MipsGotSection::writeTo method linker calculates "page" addresses and
writes them to the output.
llvm-svn: 288129
|
|
|
|
| |
llvm-svn: 288128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16
relocations is small (less that 0x10000 bytes) and occupies two adjacent
0xffff-bytes pages, current formula gives incorrect number of required "page"
GOT entries. The problem is that in time of calculation we do not know
the section address and so we cannot calculate number of 0xffff-bytes
pages exactly.
This patch fix the formula. Now it gives a correct number of pages in
the worst case when "small" section intersects 0xffff-bytes page
boundary. From the other side, sometimes it adds one more redundant GOT
entry for each output section. But usually number of output sections
referenced by GOT relocations is small.
llvm-svn: 288127
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we just remember a SymbolBody for each got entry and
duplicate a bit of logic to decide what value, if any, should be
written for that SymbolBody.
With ARM there will be more complicated values, and it seems better to
just use the relocation code to fill the got entries. This makes it
clear that each entry is filled by the dynamic linker or by the static
linker.
llvm-svn: 288107
|
|
|
|
|
|
|
| |
When we iterate over numbers as opposed to iterable elements,
parallel_for fits better than parallel_for_each.
llvm-svn: 288002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is important for cases like:
.sdata : {
*(.got.plt .got)
...
}
That was not supported before as there was no way to get access to
synthetic sections from script.
More details on review page.
Differential revision: https://reviews.llvm.org/D27040
llvm-svn: 287913
|
|
|
|
| |
llvm-svn: 287895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The .ARM.exidx table has an entry for each function with the first entry
giving the start address of the function, the table is sorted in ascending
order of function address. Given a PC value, the unwinder will search the
table for the entry that contains the PC value.
If the table entry happens to be the last, the range of the addresses that
the final unwinding table describes will extend to the end of the address
space. To prevent an incorrect address outside the address range of the
program matching the last entry we follow ld.bfd's example and add a
sentinel EXIDX_CANTUNWIND entry at the end of the table. This gives the
final real table entry an upper bound.
In addition the llvm libunwind unwinder currently depends on the presence
of a sentinel entry (PR31091).
Differential revision: https://reviews.llvm.org/D26977
llvm-svn: 287869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Offset between beginning of a .got section and _gp symbols used in MIPS
GOT relocations calculations. Usually the expression looks like
VA + Offset - GP, where VA is the .got section address, Offset - offset
of the GOT entry, GP - offset between .got and _gp. Also there two "magic"
symbols _gp_disp and __gnu_local_gp which hold the offset mentioned above.
These symbols might be referenced by MIPS relocations.
Now the linker always defines _gp symbol and uses hardcoded value for
its initialization. So offset between .got and _gp is 0x7ff0. The _gp_disp
and __gnu_local_gp defined if required and initialized by 0x7ff0.
In fact that is not correct because _gp symbol might be defined by a linker
script and holds arbitrary value. In that case we need to use this value
in relocation calculation and initialize _gp_disp and __gnu_local_gp
properly.
The patch fixes the problem and completes fixing the bug #30311.
https://llvm.org/bugs/show_bug.cgi?id=30311
Differential revision: https://reviews.llvm.org/D27036
llvm-svn: 287832
|
|
|
|
|
|
| |
Looks like we have no 32 bit bot that builds with mips support.
llvm-svn: 287799
|
|
|
|
|
|
|
| |
r287727 was not a change that broke buildbots; the other change
(r287726) that I made to LLVM broke them.
llvm-svn: 287788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have different functions to stringize objects to construct
error messages. For InputFile, we have getFilename, and for
InputSection, we have getName. You had to memorize them.
I think this is the case where the function overloading comes in handy.
This patch defines toString() functions that are overloaded for all these
types, so that you just call it in error().
Differential Revision: https://reviews.llvm.org/D27030
llvm-svn: 287787
|
|
|
|
|
|
| |
It broke buildbots.
llvm-svn: 287730
|
|
|
|
| |
llvm-svn: 287727
|
|
|
|
| |
llvm-svn: 287714
|
|
|
|
|
|
|
| |
We cannot have MipsRldMap class and In<ELFT>::MipsRldMap.
Renamed the class.
llvm-svn: 287683
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26958
llvm-svn: 287675
|
|
|
|
| |
llvm-svn: 287620
|
|
|
|
| |
llvm-svn: 287615
|
|
|
|
| |
llvm-svn: 287614
|
|
|
|
| |
llvm-svn: 287613
|
|
|
|
| |
llvm-svn: 287607
|
|
|
|
|
|
|
|
| |
Some synthetic sections are not derived calsses of SyntehticSection.
They are derived directly from InputSection. For consistencly, we should
use SyntheticSection.
llvm-svn: 287606
|
|
|
|
| |
llvm-svn: 287605
|
|
|
|
|
|
|
| |
We had five different BuildId subclasses for five different types
of build-ids. They can simply be merged to a single class.
llvm-svn: 287603
|
|
|
|
|
|
| |
This should have been moved along with r287554.
llvm-svn: 287564
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26918
llvm-svn: 287554
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26906
llvm-svn: 287549
|