| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
It's time to remove old COFF linker because the new one is now complete.
llvm-svn: 244226
|
|
|
|
|
|
|
|
| |
None of the implementations replace the SimpleFile with some other file,
they just modify the SimpleFile in-place, so a direct reference to the
file is sufficient.
llvm-svn: 240167
|
|
|
|
| |
llvm-svn: 240147
|
|
|
|
|
|
|
|
| |
SimpleFile is the only derived class of MutableFile.
This patch reduces the height of class hierarchy by removing
MutableFile class.
llvm-svn: 234354
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Import Lookup Table in Import Directory Table has the same contents
as Hint/Name Table. Symbol names imported from DLLs are pointed by
both Import Directory Table and Hint/Name Table. We had duplicate
strings there.
This patch eliminates that duplication to make the table smaller.
This should reduce binary size by the sum of lengths of imported
symbols.
llvm-svn: 233128
|
|
|
|
| |
llvm-svn: 231005
|
|
|
|
| |
llvm-svn: 230726
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nothing wrong with reinterpret_cast<llvm::support::ulittle32_t *>(loc),
but that's redundant and not great from readability point of view.
The new functions are wrappers for that kind of reinterpet_casts.
Surprisingly or unsurprisingly, there was no use of big endian read
and write. {read,write}{16,32,64}be have no user. But I think they
still worth to be there in the header for completeness.
http://reviews.llvm.org/D7927
llvm-svn: 230725
|
|
|
|
| |
llvm-svn: 222116
|
|
|
|
| |
llvm-svn: 221974
|
|
|
|
|
|
|
|
|
|
|
| |
Each entry in the delay-import address table had a wrong alignment
requirement if 32 bit. As a result it got wrong delay-import table.
Because llvm-readobj doesn't print out that field, we don't have a
test for that. I'll submit a test that would catch this bug after
improving llvm-readobj.
llvm-svn: 221853
|
|
|
|
| |
llvm-svn: 220131
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we supported x86 only. This patch is to support x64.
The array of pointers to delay-loaded functions points the
DLL delay loading function at start-up. When a function is called
for the first time, the delay loading function gets called and
then rewrite the function pointer array.
llvm-svn: 220096
|
|
|
|
|
|
|
|
|
|
| |
This patch creates the import address table and sets its
address to the delay-load import table. This also creates
wrapper functions for __delayLoadHelper2.
x86 only for now.
llvm-svn: 219948
|
|
|
|
|
|
|
|
| |
Previously the field was not set. The field should be pointing to
a placeholder where the DLL delay-loader writes the base address
of a DLL.
llvm-svn: 219415
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial patch to emit the delay-import table. With this,
LLD is now able to emit the table that llvm-readobj can read and
dump.
The table lacks a few fields, such as the address of HMODULE, the
import address table, etc. They'll be added in subsequent patches.
llvm-svn: 219384
|
|
|
|
| |
llvm-svn: 219348
|
|
|
|
|
|
|
| |
I'm going to use this function both for the import table and the
delay-import table.
llvm-svn: 219267
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 219246
|
|
|
|
|
|
|
| |
Export table entry is 64 bit wide in x64. If MSB is 1, it means it's
imported by ordinal. The shift value was wrong.
llvm-svn: 218728
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation of AMD64 relocations was imcomplete
and wrong. On AMD64, we of course have to use AMD64
relocations instead of i386 ones. This patch fixes the
issue.
LLD is now able to link hello64.obj (created from
hello64.asm) against user32.lib and kernel32.lib to
create a Win64 binary.
llvm-svn: 216253
|
|
|
|
|
|
|
| |
I'm adding new parameters to the function, and the existing
parameter with a default argument is found confusing.
llvm-svn: 216153
|
|
|
|
|
|
|
| |
Import tables in the PE+ format is an array of 64 bit numbers,
although the executable size is still limited to 4GB in PE+.
llvm-svn: 216039
|
|
|
|
|
|
|
|
| |
Because the files in Core actually depend on these files.
Differential Revision: http://reviews.llvm.org/D4000
llvm-svn: 210710
|
|
|
|
|
|
|
|
|
| |
"x.empty()" is more idiomatic than "x.size() == 0". This patch is to
add such method and use it in LLD.
Differential Revision: http://llvm-reviews.chandlerc.com/D3279
llvm-svn: 205558
|
|
|
|
|
|
| |
We had lld::coff and lld::pecoff namespaces for no reason. Unify them.
llvm-svn: 197201
|
|
|
|
|
|
|
| |
The file currently has only one function. Function that is useful both for
IdataPass and EdataPass will be added to that file.
llvm-svn: 197140
|
|
|
|
|
|
|
| |
DLLNameAtom is an atom whose content is a string. IdataAtom is not going to
be the only place we need such atom, so I want to generalize it.
llvm-svn: 197137
|
|
|
|
| |
llvm-svn: 197018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 197016
|
|
llvm-svn: 195618
|