| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 204223
|
| |
|
|
| |
llvm-svn: 202998
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
We had lld::coff and lld::pecoff namespaces for no reason. Unify them.
llvm-svn: 197201
|
| |
|
|
| |
llvm-svn: 197039
|
| |
|
|
|
|
| |
No change in functionality.
llvm-svn: 196053
|
| |
|
|
|
|
|
|
|
| |
This patch won't change the output because the layout of linker internal
atoms is forced by layout-{before,after} references. Ordinals of the linker
internal atoms are not currently used. (That's why it's working even if there
are atoms having the same ordinals.)
llvm-svn: 195610
|
| |
|
|
|
|
|
|
|
|
| |
This patch does not change the meaning of the program, but if something's wrong
in the linker or the compiler and the control reaches to the gap of imported
function table, it will stop immediately because of the presence of INT3. If
NOP, it'd fall through to the next call instruction, which is usually a
completely foreign function call.
llvm-svn: 194860
|
| |
|
|
| |
llvm-svn: 194851
|
| |
|
|
| |
llvm-svn: 194037
|
| |
|
|
| |
llvm-svn: 192261
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The import name is not always the same as the symbol name. If the name/type
field in the import header is NOPREFIX or UNDECORATE, we need to strip some
characters from symbol to get its import name.
The Microsoft PE/COFF spec is vague if symbol contains more than two
consecutive characters to be stripped. We used to strip all characters,
but it doesn't seem right as we couldn't link against the system library
because of this name mangling. Looks like we shouldn't strip more than one
character.
llvm-svn: 188154
|
| |
|
|
|
|
|
|
|
| |
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
|
| |
|
|
| |
llvm-svn: 187484
|
| |
|
|
|
|
|
|
| |
This patch removes hacky mangle() function, which strips all decorations
uncondtitionally. LLD now interprets Import Name/Type field in the import
library properly as described in the Microsoft PE/COFF Spec.
llvm-svn: 187388
|
| |
|
|
| |
llvm-svn: 187382
|
| |
|
|
| |
llvm-svn: 187214
|
| |
|
|
| |
llvm-svn: 186888
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new pass, IdataPass, to transform shared atom references
to real references and to construct the .idata section data. With this patch
lld can produce a working Hello World program by linking it against
kernel32.dll and user32.dll.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1096
llvm-svn: 186071
|
| |
|
|
|
|
|
|
|
|
| |
A hint is an index of the export pointer table in a DLL, at which
PE/COFF loader starts looking for a symbol name. The import library
comes with hints and symbol pairs, and as long as hints are in sync
with the actual symbol table in DLL, the symbols will be resolved
quickly. So, we shouldn't ignore hints but propagate them to an output.
llvm-svn: 185516
|
| |
|
|
|
|
| |
class.
llvm-svn: 185515
|
| |
|
|
| |
llvm-svn: 185307
|
| |
|
|
| |
llvm-svn: 185285
|
| |
|
|
| |
llvm-svn: 185283
|
|
|
This is the first patch toward full DLL support. With this patch, lld can
read .lib file for a DLL.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D987
llvm-svn: 184101
|