| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
When a relocation is applied to a location, the new value needs
to be added to the existing value at the location. Existing
value is in most cases zero, but if not, the current code does
not work.
llvm-svn: 216680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Image Base field in the PE/COFF header is used as hint for the loader.
If the loader can load the executable at the specified address, that's
fine, but if not, it has to load it at a different address.
If that happens, the loader has to fix up the addresses in the
executable by adding the offset. The list of addresses that need to
be fixed is in .reloc section.
This patch is to emit x64 .reloc section contents.
llvm-svn: 216636
|
|
|
|
|
|
|
|
| |
IMAGE_REL_AMD64_ADDR64 relocation should set 64-bit *VA* (virtual
address) instead of *RVA* (relative virtual address), so we have
to add the iamge base to the target's RVA.
llvm-svn: 216512
|
|
|
|
|
|
|
| |
This is yet another command line flag to set a bit in
DLLCharacteristics. Default on Win64 is "on".
llvm-svn: 216414
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PE/COFF spec says that SizeOfRawData field in the section
header must be a multiple of FileAlignment from the optional
header. LLD emits 512 as FileAlignment, so it must have been
a multiple of 512.
LLD did not follow that. It emitted the actual section size
without the last padding as the SizeOfRawData. Although it's
not correct as per the spec, the Windows loader doesn't seem
to actually bother to check that. Executables created by LLD
worked fine.
However, tools dealing with executalbe files may expect it
to be the correct value, and one instance of it is mt.exe
tool distributed as a part of Windows SDK.
If CMake is invoked with "-E vs_link_exe" option, it silently
run mt.exe to embed a resource file to the resulting file.
And mt.exe sometimes breaks an input file if it's section
header does not follow the standard. That caused a misterous
error that CMake with Ninja occasionally produces a broken
executable.
This patch fixes the section header to make mt.exe and
other tools happy.
llvm-svn: 214453
|
|
|
|
|
|
|
| |
Because of a bug, the entry point address in the PE/COFF header
was not correct.
llvm-svn: 213802
|
|
|
|
|
|
|
| |
Windows loader can load a DLL without this bit but it wouldn't
call the initializer function in the DLL if the bit is absent.
llvm-svn: 213216
|
|
|
|
|
|
|
| |
The resource table entry should have the RVA of the
embedded resource file.
llvm-svn: 212765
|
|
|
|
|
|
| |
A refactoring, with the added benefit of helping OS X builds.
llvm-svn: 211371
|
|
|
|
| |
llvm-svn: 210785
|
|
|
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, LLD edition.
IF you want to know more details about this, you can see the recent
commits to Debug.h in LLVM. This is just the LLD segment of a cleanup
I'm doing globally for this macro.
llvm-svn: 206851
|
|
|
|
|
|
|
|
| |
This results in some simplifications to the code where an OwningPtr had to
be used with the previous api and then ownership moved to a unique_ptr for
the rest of lld.
llvm-svn: 203809
|
|
|
|
| |
llvm-svn: 203666
|
|
|
|
| |
llvm-svn: 202998
|
|
|
|
|
|
|
|
|
| |
Just like x86 exception handler table, the table for x64 needs to be sorted
so that runtime can binary search on it. Unlike x86, the table entry for x64
has multiple fields, and they need to be sorted according to its BeginAddress
field. This patch also fixes a bug in relocations.
llvm-svn: 202874
|
|
|
|
|
|
|
|
|
| |
It looks like the contents of the table need to be sorted according to its
value, so that the runtime can find the entry by binary search. I'm not 100%
sure if we really have to do that, but at least I can say it's safe to do
because the contents of .sxdata is just a list of exception handlers' RVAs.
llvm-svn: 202550
|
|
|
|
| |
llvm-svn: 202527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If all input files are compatible with Structured Exception Handling, linker
is supposed to create an exectuable with a table for SEH handlers. The table
consists of exception handlers entry point addresses.
The basic idea of SEH in x86 Microsoft ABI is to list all valid entry points
of exception handlers in an read-only memory, so that an attacker cannot
override the addresses in it. In x86 ABI, data for exception handling is mostly
on stack, so it's volnerable to stack overflow attack. In order to protect
against it, Windows runtime uses the table to check a return address, to
ensure that the address is really an valid entry point for an exception handler.
Compiler emits a list of exception handler functions to .sxdata section. It
also emits a marker symbol "@feat.00" to indicate that the object is compatible
with SEH. SEH is a relatively new feature for COFF, and mixing SEH-compatible
and SEH-incompatible objects will result in an invalid executable, so is the
marker.
If all input files are compatible with SEH, LLD emits a SEH table. SEH table
needs to be pointed by Load Configuration strucutre, so when emitting a SEH
table LLD emits it too. The address of a Load Configuration will be stored to
the file header.
llvm-svn: 202248
|
|
|
|
|
|
| |
IMAGE_DLL_CHARACTERISTICS_NO_SEH flag should be set only when SEH is disabled.
llvm-svn: 202215
|
|
|
|
|
|
|
| |
The charcateristics field should not have IMAGE_FILE_32BIT_MACHINE bit but have
IMAGE_FILE_LARGE_ADDRESS_AWARE bit for PE32+.
llvm-svn: 200518
|
|
|
|
|
|
|
| |
The PE32+ loader does not seem to like an executable with an empty section, so
we should not emit a section if it's empty.
llvm-svn: 200514
|
|
|
|
| |
llvm-svn: 200278
|
|
|
|
| |
llvm-svn: 200240
|
|
|
|
| |
llvm-svn: 200185
|
|
|
|
|
|
|
| |
The optional header for PE32+ is a bit larger than PE32 because some of
its fields are extended to 8 bytes.
llvm-svn: 200184
|
|
|
|
| |
llvm-svn: 200128
|
|
|
|
| |
llvm-svn: 200107
|
|
|
|
| |
llvm-svn: 200106
|
|
|
|
| |
llvm-svn: 200052
|
|
|
|
| |
llvm-svn: 200019
|
|
|
|
| |
llvm-svn: 198634
|
|
|
|
| |
llvm-svn: 198396
|
|
|
|
|
|
|
|
|
|
|
| |
If the linker is instructed to create a DLL, it will also create an import
library (.lib file) to describe the symbols exported by the DLL. This patch is
to create the import library file.
There is a convenient command "lib.exe" which can create an import library
from a module definition file (.def file). The command is used in this patch.
llvm-svn: 197801
|
|
|
|
| |
llvm-svn: 197788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes are in:
include/lld/Core/Reference.h
include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.
1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers. It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.
The new model is that there is a global Registry object. You programmatically
register the Readers you want with the registry object. Whenever you need to
read/parse a file, you ask the registry to do it, and the registry tries each
registered reader.
For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object.
2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings. Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values. The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value. This tuple system allows conversion to and from strings with
no ambiguities.
llvm-svn: 197727
|
|
|
|
|
|
|
| |
Executable files do not use a string table, so section names longer than 8
characters are not permitted. Long section names should just be truncated.
llvm-svn: 197470
|
|
|
|
| |
llvm-svn: 197375
|
|
|
|
|
|
| |
Because it's now able to emit not only executable but DLL.
llvm-svn: 197374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first patch to emit data for the DLL export table. The DLL export
table is the data used by the Windows loader to find the address of exported
function from DLL. With this patch, LLD is able to emit a valid DLL export
table which the Windows loader can interpret and load.
The data structure of the DLL export table is described in the Microsoft
PE/COFF Specification, section 5.3.
DLL support is not complete yet; the linker needs to emit an import library
for a DLL, otherwise the linker cannot link against the DLL. We also do not
support export-only-by-ordinal yet.
llvm-svn: 197212
|
|
|
|
| |
llvm-svn: 197039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, we had the following class hierarchy.
Chunk -> AtomChunk -> SectionChunk -> GenericSectionChunk
-> BaseRelocChunk
-> HeaderChunk
Chunk represented the generic concept of contiguous range in an output
file. AtomChunk represented a chunk consists of atoms.
That class hierarchy had many issues: 1) BaseRelocChunk does not really
consist of atoms, so inheriting from AtomChunk was plainly wrong, and 2)
the hierarchy is unecessarily too deep.
This patch correct them. The new hierachy is shown below.
Chunk -> SectionChunk -> AtomChunk
-> BaseRelocChunk
-> HeaderChunk
In the new hierarchy, AtomChunk represents a chunk consists of atoms. Other
types of sections (currently only BaseRelocChunk) should inherit directly
from SectionChunk.
llvm-svn: 197038
|
|
|
|
|
|
| |
Also removed unused field.
llvm-svn: 197027
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 197025
|
|
|
|
|
|
|
| |
Because sections no longer have trailing NULL bytes, size() and rawSize() now
return the same value.
llvm-svn: 197020
|
|
|
|
| |
llvm-svn: 197019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 197009
|
|
|
|
| |
llvm-svn: 197008
|
|
|
|
| |
llvm-svn: 197007
|