| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 321769
|
|
|
|
| |
llvm-svn: 321768
|
|
|
|
| |
llvm-svn: 321738
|
|
|
|
| |
llvm-svn: 321737
|
|
|
|
| |
llvm-svn: 321736
|
|
|
|
| |
llvm-svn: 321734
|
|
|
|
|
|
|
| |
We normally add checks on the architecture independent Expr instead of
on the architecture dependent relocation type.
llvm-svn: 321733
|
|
|
|
| |
llvm-svn: 321688
|
|
|
|
|
|
|
| |
If a section is RW there is no reason to drop a relocation with a weak
undefined symbol.
llvm-svn: 321684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We normally want to ignore SHT_NOBITS sections when computing
offsets. The sh_offset of section itself seems to be irrelevant and
- If the section is in the middle of a PT_LOAD, it will make no
difference on the computed offset of the followup section.
- If it is in the end of a PT_LOAD, we want to avoid its alignment
changing the offset of the followup sections.
The issue is if it is at the start of the PT_LOAD. In that case we do
have to align it so that the following sections have congruent address
and offset module the page size. We were not handling this case.
This should fix freebsd kernel link.
llvm-svn: 321657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocations only.
This is "Bug 35751 - .dynamic relocation entries omitted if output
contains only IFUNC relocations"
We have InX::RelaPlt and InX::RelaIPlt synthetic sections for PLT relocations.
They are usually live in rela.plt section. Problem appears when InX::RelaPlt
section is empty. In that case we did not produce normal set of dynamic tags
required, because logic was written in the way assuming we always have
non-IRelative relocations in rela.plt.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41592
llvm-svn: 321600
|
|
|
|
|
|
|
|
|
|
| |
This was raised in comments for D41592.
With current code we always assign parent
section for Rel[a] sections like
InX::RelaPlt or InX::RelaDyn, so checking
their parent for null is excessive.
llvm-svn: 321581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If using a version script with a `local: *` in it, symbols in shared
libraries will still get default visibility if another shared library on
the link line has an undefined reference to the symbol. This is quite
surprising. Neither bfd nor gold have this behavior when linking a
shared library, and none of LLD's tests fail without this behavior, so
it seems safe to limit scanShlibUndefined to executables.
As far as executables are concerned, gold doesn't do any automatic
default visibility marking, and bfd issues a link error about a shared
library having a reference to a hidden symbol rather than silently
giving that symbol default visibility. I think bfd's behavior here is
preferable to LLD's, but that's something to be considered in a
follow-up.
Differential Revision: https://reviews.llvm.org/D41524
llvm-svn: 321578
|
|
|
|
|
|
|
|
|
|
| |
This makes adjustExpr a bit simpler too IMHO.
It seems that some of the complication around relocation processing
is that we are trying to create copy relocations too early. It seems
we could handle a few simple cases first and continue.
llvm-svn: 321507
|
|
|
|
|
|
| |
I will send a followup patch removing the FIXME this patch adds.
llvm-svn: 321499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we failed to resolve them when produced executables:
"relocation R_X86_64_32 cannot be used against shared object; recompile with -fPIC"
Patch fixes it so that we resolve them to 0 for executables.
And for -shared case we still should produce the relocation.
This finishes fixing PR35720.
DIfferential revision: https://reviews.llvm.org/D41551
llvm-svn: 321473
|
|
|
|
|
|
|
|
|
| |
This is an aesthetic change to represent a placeholder for later
binary patching as "0, 0, 0, 0" instead of "0x00, 0x00, 0x00, 0x00".
The former is how we represent it in COFF, and I found it easier to
read than the latter.
llvm-svn: 321471
|
|
|
|
| |
llvm-svn: 321458
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41577
llvm-svn: 321453
|
|
|
|
|
|
|
|
|
|
|
| |
If a relocation cannot be implemented by the dynamic linker and the
section is rw, allow creating a plt entry to use as the function
address as if the section was ro.
This matches bfd and gold. It also matches our behavior with -z
notext.
llvm-svn: 321430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and data commands.
Advance the memory region offset when handling a linker script data
command such as BYTE or LONG. Failure to advance the offset results
in corrupted output with overlapping sections.
Update tests to check for this combination of both a) memory regions
and b) data commands.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35565
Patch by Owen Shaw!
llvm-svn: 321418
|
|
|
|
|
|
|
|
|
|
| |
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
|
|
|
|
| |
llvm-svn: 321403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of PR35720.
Currently LLD allows dynamic relocations against text when -z notext is given.
Though for non-PIC relocations like R_X86_64_PC32 that does not work,
we produce "relocation R_X86_64_PC32 cannot be used against shared object;"
error because they may overflow in runtime.
Solution implemented is to use PLT for them.
Differential revision: https://reviews.llvm.org/D41541
llvm-svn: 321400
|
|
|
|
| |
llvm-svn: 321393
|
|
|
|
|
|
|
|
|
|
| |
When two linker script symbols are subtracted, the result should be absolute.
This is the behavior of binutils' ld.
Patch by Erick Reyes!
llvm-svn: 321390
|
|
|
|
|
|
|
| |
This small function was showing up in the profile. Defining it inline
gives about 0.3% speedup.
llvm-svn: 321317
|
|
|
|
|
|
|
|
|
| |
It is a pretty expensive function. Some of the speedups:
clang: 1.92%
chrome: 1.15%
linux-kernel: 1.40%
llvm-svn: 321311
|
|
|
|
|
|
|
| |
This simplifies toRegularSection and reduces the noise in a followup
patch.
llvm-svn: 321240
|
|
|
|
|
|
|
| |
We use null files in sections to represent linker created sections,
so ObjFile<ELFT> is never null.
llvm-svn: 321238
|
|
|
|
|
|
|
| |
It was only templated so it could create a dummy section header that
was immediately parsed back.
llvm-svn: 321235
|
|
|
|
|
|
| |
There should be no null sections in InputSections.
llvm-svn: 321219
|
|
|
|
| |
llvm-svn: 321216
|
|
|
|
| |
llvm-svn: 321199
|
|
|
|
|
|
| |
It is never null.
llvm-svn: 321198
|
|
|
|
| |
llvm-svn: 321196
|
|
|
|
| |
llvm-svn: 321194
|
|
|
|
|
|
| |
Every shared symbol has a file, so we can use a reference.
llvm-svn: 321187
|
|
|
|
| |
llvm-svn: 321186
|
|
|
|
| |
llvm-svn: 321185
|
|
|
|
|
|
|
|
| |
The value of the symbol in the assignment should include the sentinel entry.
Differential Revision: https://reviews.llvm.org/D41234
llvm-svn: 321154
|
|
|
|
|
|
| |
The variable being casted was accessed in the previous line.
llvm-svn: 321140
|
|
|
|
|
|
|
| |
These values are trivially never null. While at it, also use
InputSection instead of InputSectionBase when possible.
llvm-svn: 321126
|
|
|
|
| |
llvm-svn: 321081
|
|
|
|
|
|
|
|
| |
It is not necessary and matches what bfd and gold do.
This was a regression from r315658.
llvm-svn: 321023
|
|
|
|
| |
llvm-svn: 321022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A more efficient PLT sequence can be used when the distance between the
.plt and the end of the .plt.got is less than 128 Megabytes, which is
frequently true. We fall back to the old sequence when the offset is larger
than 128 Megabytes. This gives us an alternative to forcing the longer
entries with --long-plt as we gracefully fall back to it as needed.
See ELF for the ARM Architecture Appendix A for details of the PLT sequence.
Differential Revision: https://reviews.llvm.org/D41246
llvm-svn: 320987
|
|
|
|
|
|
|
|
|
|
|
| |
We add dynamic section entries both in the ctor of the class and
DynamicSection::finalizeContents(). Some entries need to be added early
in the ctor because they add strings to .dynstr. Other entries were
intended to be added in finalizeContents(). However, some entries are
added in the ctor even though they don't add strings. This patch
fix the issue.
llvm-svn: 320851
|
|
|
|
|
|
|
|
|
| |
I noticed that the continue this patch deletes was not tested. Trying
to add a test I realized that we never put a VER_NDX_LOCAL symbol in
the dynamic symbol table. There doesn't seem to be any reason for a
linker to use VER_NDX_LOCAL for a defined shared symbol.
llvm-svn: 320817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARM.exidx section contains a table of 8-byte entries with the first
word of each entry an offset to the function it describes and the second
word instructions for unwinding if an exception is thrown from that
function. The SHF_LINK_ORDER processing will order the table in ascending
order of the functions described by the exception table entries. As the
address range of an exception table entry is terminated by the next table
entry, it is possible to merge consecutive table entries that have
identical unwind instructions.
For this implementation we define a table entry to be identical if:
- Both entries are the special EXIDX_CANTUNWIND.
- Both entries have the same inline unwind instructions.
We do not attempt to establish if table entries that are references to
.ARM.extab sections are identical.
This implementation works at a granularity of a single .ARM.exidx
InputSection. If all entries in the InputSection are identical to the
previous table entry we can remove the InputSection. A more sophisticated
but more complex implementation would rewrite InputSection contents so that
duplicates within a .ARM.exidx InputSection can be merged.
Differential Revision: https://reviews.llvm.org/D40967
llvm-svn: 320803
|