The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers. On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.
rdar://problem/24572729
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@260271 91177308-0d34-0410-b5e6-96231b3b80d8
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@259574 91177308-0d34-0410-b5e6-96231b3b80d8
An upcoming patch will use this to create lists of ObjC methods.
Adding it now to reduce the amount of code in that patch.
Test cases will follow in the other patch too.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@259440 91177308-0d34-0410-b5e6-96231b3b80d8
This pass currently emits an objc image info section if one is required.
This section contains the aggregated version and flags for all of the input
files.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@258197 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides generation of .ARM.exidx & .ARM.extab sections which are
used for unwinding. The patch adds new content type typeARMExidx for atoms from
.ARM.exidx section and integration of atoms with such type to the ELF
ReaderWriter. exidx.test has been added with checking of contents of .ARM.exidx
section and .ARM.extab section.
Differential Revision: http://reviews.llvm.org/D9324
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@236873 91177308-0d34-0410-b5e6-96231b3b80d8
This caused some tests to fail on FreeBSD, and Mac OS X.
Some std::sort() implementations will check for strict-weak-ordering
by comparing with the same element, or will compare an element to
itself for 1-element sequence. Take care of this case. Thanks to
chandlerc for explaning that to me.
Reviewed by: ruiu
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@227709 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we applied the LayoutPass to order atoms and then
apply elf::ArrayOrderPass to sort them again. The first pass is
basically supposed to sort atoms in the normal fashion (which
is to sort symbols in the same order as the input files).
The second pass sorts atoms in {init,fini}_array.<priority> by
priority.
The problem is that the LayoutPass is overkill. It analyzes
references between atoms to make a decision how to sort them.
It's slow, hard to understand, and above all, it doesn't seem
that we need its feature for ELF in the first place.
This patch remove the LayoutPass from ELF pass list. Now all
reordering is done in elf::OrderPass. That pass sorts atoms by
{init,fini}_array, and if they are not in the special section,
they are ordered as the same order as they appear in the command
line. The new code is far easier to understand, faster, and
still able to create valid executables.
Unlike the previous layout pass, elf::OrderPass doesn't count
any attributes of an atom (e.g. permissions) except its
position. It's OK because the writer takes care of them if we
have to.
This patch changes the order of final output, although that's
benign. Tests are updated.
http://reviews.llvm.org/D7278
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@227666 91177308-0d34-0410-b5e6-96231b3b80d8
On darwin in final linked images, the __TEXT segment covers that start of the
file. That means in memory a process can see the mach_header (and load commands)
for every loaded image in a process. There are APIs that take and return the
mach_header addresses as a way to specify a particular loaded image.
For completeness, any code can get the address of the mach_header of the image
it is in by using &__dso_handle. In addition there are mach-o type specific
symbols like __mh_execute_header.
The linker needs to supply a definition for any of these symbols if used. But
the address the symbol it resolves to is not in any section. Instead it is the
address of the start of the __TEXT segment.
I needed to make a small change to SimpleFileNode to not override
resetNextIndex() because the Driver creates a SimpleFileNode to hold the
internal/implicit files that the context/writer can create. For some reason
SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting
the index (which mach-o needs if the internal file is an archive).
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@221822 91177308-0d34-0410-b5e6-96231b3b80d8
Darwin uses two-level-namespace lookup for symbols which means the static
linker records where each symbol must be found at runtime. Thus defining a
symbol in a dylib loaded earlier will not effect where symbols needed by
later dylibs will be found. Instead overriding is done through a section
of type S_INTERPOSING which contains tuples of <interposer, interposee>.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@221421 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimally useful pass to construct the __unwind_info section in a
final object from the various __compact_unwind inputs. Currently it doesn't
produce any compressed pages, only works for x86_64 and will fail if any
function ends up without __compact_unwind.
rdar://problem/18208653
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@218703 91177308-0d34-0410-b5e6-96231b3b80d8
.gnu.linkonce sections are similar to section groups.
They were supported before section groups existed and provided a way
to resolve COMDAT sections using a different design.
There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant in a binary.
.gnu.linkonce based symbol resolution achieves that.
Review : http://llvm-reviews.chandlerc.com/D3242
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@205280 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 5d5ca72a7876c3dd3dd1db83dc6a0d74be9e2cd1.
Discuss on a better design to raise error when there is a similar group with Gnu
linkonce sections and COMDAT sections.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@205224 91177308-0d34-0410-b5e6-96231b3b80d8
.gnu.linkonce sections are similar to section groups. They were supported before
section groups existed and provided a way to resolve COMDAT sections using a
different design. There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant. .gnu.linkonce based symbol resolution achieves that.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@205163 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is to basically move the functionality to construct Data Directory
from IdataPass to WriterPECOFF.
Data Directory is a part of the PE/COFF header and contains the addresses of
the import tables.
We used to represent the link from Data Directory to the import tables as
relocation references. The idea behind it is that, because relocation
references are processed by the Writer, we wouldn't have to do anything special
to fill the addresses of the import tables. I thought that the addresses would
be set "automatically".
But it turned out that that design made the pass and the writer rather
complicated. In order to make relocation references between Data Directory to
the import tables, these data structures needed to be represented as Atom.
However, because Data Directory is not a section content but a part of the
PE/COFF header, it did not fit well as an Atom. So we ended up having
complicated code both in IdataPass and the writer.
This patch simplifies it.
One side effect of this patch is that we now have ".idata.a", ".idata.d" and
"idata.t" sections for the import address table, the import directory table,
and the import lookup table. The writer looks for the sections by name to find
the start addresses of the sections. We probably should have a better way to
find a specific atom from the core linking result, but currently using the
section name seems to be the easiest way to do that. The Windows loader do not
care about the import table's section layout.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@197016 91177308-0d34-0410-b5e6-96231b3b80d8
This also makes it support debugging executables built with lld.
Initial patch done by Bigcheese. This is only a revised patch to
have the functionality in the Writer.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@191032 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like there is a possibility of seeing RO/RW note sections
and we would need to create an appropriate RO/RW segment associated
with them.
Adds a test too.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@189907 91177308-0d34-0410-b5e6-96231b3b80d8
Davide Italiano
Rafael Espindola
Pete Cooper
Lang Hames
Denis Protivensky
Leny Kholodov
Rui Ueyama
Nick Kledzik
Shankar Easwaran
Tim Northover
Shankar Easwaran