MipsReginfoInputSection is basically just a container of Elf_Mips_Reginfo
struct. This patch makes that struct directly accessible from others.
llvm-svn: 256984
Unlike ObjectFile or ArchiveFile, SharedFile had two parse functions,
parseSoName() and parse(). parse must have been called after parseSoName,
but that requirement was not obvious from their names. (So it looked
like you could call parse() on a shared object file right away.)
This patch rename parseRest. It is now obvious that there's no single
parse function for the shared object file.
llvm-svn: 256898
Previously, we handle archive files with --whole-archive this way:
create instances of ArchiveFile, call getMembers to obtain memory
buffers of archive members, and create ObjectFiles for the members.
We didn't call anything except getMembers if --whole-archive was
specified.
I noticed that we didn't actually have to create ArchiveFile instaces
at all for that case. All we need is to get a list of memory buffers
for members, which can be done by a non-member function.
This patch removes getMembers member function from ArchiveFile.
Also removed unnecessary code for memory management.
llvm-svn: 256893
Test did not catch this either, so I`ll improve it and recommit later.
Original commit message:
[ELF] - Optimize .eh_frame section: remove CIE if all FDEs referencing it were removed.
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256693
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256638
The linker has to create __tls_get_addr, end and _end symbols.
Previously, these symbols were created in createSections().
But they are not actually related to creating output sections.
This patch moves code out of the function.
llvm-svn: 256441
Previously, this code was directly written in createSections()
function. This patch moves some code out of that function to a
new class.
llvm-svn: 256438
The number of output sections is usually limited, so the cost
of allocating them is not a bottleneck. This patch simplifies
the code by removing the allocators.
llvm-svn: 256437
OutputSectionBase already has virtual member functions.
This patch makes addSection() a virtual function to remove code
from Writer::createSections().
llvm-svn: 256436
The R_MIPS_GPREL16 / R_MIPS_GPREL32 relocations use the following
expressions for calculations:
```
local symbol: S + A + GP0 - GP
global symbol: S + A - GP
GP - Represents the final gp value, i.e. _gp symbol
GP0 - Represents the gp value used to create the relocatable object
```
The GP0 value is taken from the .reginfo data section defined by an object
file. To implement that I keep a reference to `MipsReginfoInputSection`
in the `ObjectFile` class. This reference is used by the
`ObjectFile::getMipsGp0` method to return the GP0 value.
Differential Revision: http://reviews.llvm.org/D15760
llvm-svn: 256416
The file crtbeginT.o has relocations pointing to the start of an empty
.eh_frame that is known to be the first in the link. It does that to
identify the start of the output .eh_frame. Handle this special case.
Differential revision: http://reviews.llvm.org/D15610
llvm-svn: 256414
This function was longer than 250 lines, which is way too long
in my own standard. This patch reduces the size. It is still
too long, but this patch should be toward the right direction.
llvm-svn: 256411