| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix is to handle local symbols referring to SHF_MERGE sections.
Original message:
GC entries of SHF_MERGE sections.
It is a fairly direct extension of the gc algorithm. For merge sections
instead of remembering just a live bit, we remember which offsets
were used.
This reduces the .rodata sections in chromium from 9648861 to 9477472
bytes.
llvm-svn: 267233
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r267164.
Revert "Trying to fix the windows build."
This reverts commit r267168.
Debugging a bootstrap problem.
llvm-svn: 267194
|
|
|
|
| |
llvm-svn: 267168
|
|
|
|
|
|
|
|
|
|
|
| |
It is a fairly direct extension of the gc algorithm. For merge sections
instead of remembering just a live bit, we remember which offsets were
used.
This reduces the .rodata sections in chromium from 9648861 to 9477472
bytes.
llvm-svn: 267164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that this will read data from the section to properly
handle Elf_Rel implicit addends.
Sorry for the noise.
Original messages:
Try to fix Windows lld build.
Move getRelocTarget to ObjectFile.
It doesn't use anything from the InputSection.
llvm-svn: 267163
|
|
|
|
|
|
| |
It doesn't use anything from the InputSection.
llvm-svn: 267154
|
|
|
|
|
|
| |
In all currently supported cases this is a nop.
llvm-svn: 266888
|
|
|
|
|
|
|
| |
This avoids computing the address of a position in the got just to then
subtract got->getva().
llvm-svn: 266831
|
|
|
|
| |
llvm-svn: 266609
|
|
|
|
|
|
|
|
| |
This requires adding a few more expression types, but is already a small
simplification. Having Writer.cpp know the exact expression will also
allow further simplifications.
llvm-svn: 266604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we use the first scan over the relocations to remember
the information we found about them: will them be relaxed, will a plt be
used, etc.
With that the actual relocation application becomes much simpler. That
is particularly true for the interfaces in Target.h.
This unfortunately means that we now do two passes over relocations for
non SHF_ALLOC sections. I think this can be solved by factoring out the
code that scans a single relocation. It can then be used both as a scan
that record info and for a dedicated direct relocation of non SHF_ALLOC
sections.
I also think it is possible to reduce the number of enum values by
representing a target with just an OutputSection and an offset (which
can be from the start or end).
This should unblock adding features like relocation optimizations.
llvm-svn: 266158
|
|
|
|
|
|
| |
Give them values instead of computing it during relocation.
llvm-svn: 265986
|
|
|
|
| |
llvm-svn: 265404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
|
|
|
|
|
|
|
| |
This matches the behavior of both bfd and gold. Looks like we just got
here for mips because of a bad ordering of an if else chain.
llvm-svn: 265147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
|
|
|
|
|
|
| |
Pass only one of them to relocateOne.
llvm-svn: 264866
|
|
|
|
|
|
|
| |
It is now added to the addend in the same way as a regular Elf_Rel
addend.
llvm-svn: 264864
|
|
|
|
|
|
|
| |
Because of merge sections it is not sufficient to just add them while
applying a relocation.
llvm-svn: 264863
|
|
|
|
|
|
|
| |
The original comments were separated by new code that is irrelevant to
the comment. This patch moves the comment to the right place and update it.
llvm-svn: 264816
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies a few things
* Read the value as early as possible, instead of passing a pointer to
the location.
* Print the warning for missing pair close to where we find out it is
missing.
* Don't pass the value to relocateOne.
llvm-svn: 264802
|
|
|
|
| |
llvm-svn: 264267
|
|
|
|
|
|
|
| |
This reverts commit r263799.
It was a mistake. Sorry about that.
llvm-svn: 263801
|
|
|
|
| |
llvm-svn: 263799
|
|
|
|
| |
llvm-svn: 263510
|
|
|
|
| |
llvm-svn: 263391
|
|
|
|
|
|
|
|
|
| |
We want to make SymbolBody the central place to query symbol information.
This patch also renames canBePreempted to isPreemptible because I feel that
the latter is slightly better (the former is three words and the latter
is two words.)
llvm-svn: 263386
|
|
|
|
|
|
| |
NFC. Follow-up to r263381.
llvm-svn: 263382
|
|
|
|
|
|
|
|
|
|
|
| |
functions. NFC.
The patch does not reduce the size of the code but makes
InputSectionBase::relocate cleaner a bit.
Differential Revision: http://reviews.llvm.org/D18119
llvm-svn: 263381
|
|
|
|
| |
llvm-svn: 263368
|
|
|
|
|
|
| |
The control reaches here only when linking MIPS binaries.
llvm-svn: 263359
|
|
|
|
| |
llvm-svn: 263356
|
|
|
|
|
|
| |
call it from the single place. NFC.
llvm-svn: 263339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which was reverted because included
unrelative changes by mistake.
Original commit message:
[ELF] - Change all messages to lowercase to be consistent.
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263337
|
|
|
|
|
|
| |
This reverts commit r263252 because the change contained unrelated changes.
llvm-svn: 263272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263252
|
|
|
|
| |
llvm-svn: 263251
|
|
|
|
| |
llvm-svn: 263249
|
|
|
|
| |
llvm-svn: 263237
|
|
|
|
|
|
| |
symbols. NFC.
llvm-svn: 263236
|
|
|
|
|
|
|
|
| |
It is really odd that Mips differentiates symbols that are born local
and those that become local because of hidden visibility. I don't know
enough mips to known if this is a bug or not.
llvm-svn: 263228
|
|
|
|
| |
llvm-svn: 263227
|
|
|
|
| |
llvm-svn: 263226
|
|
|
|
| |
llvm-svn: 263225
|
|
|
|
|
|
| |
pr26878 shows a case where locals have to be in the got.
llvm-svn: 263222
|
|
|
|
| |
llvm-svn: 263152
|
|
|
|
|
|
|
| |
It doesn't look like anything is depending on using local dynamic tls
relocations with preemptable symbols.
llvm-svn: 262957
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
|
|
|
|
|
|
|
|
|
| |
Get rid of few accessors in that class, and replace
them with direct fields access.
Differential revision: http://reviews.llvm.org/D17879
llvm-svn: 262796
|
|
|
|
|
|
|
| |
The rules for when we can relax tls relocations are target independent.
The only things that are target dependent are the relocation values.
llvm-svn: 262748
|