| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 219348
|
|
|
|
| |
llvm-svn: 219341
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Use x86 and x64 which is the canonical Microsoft vernacular for the targets.
Addresses post-commit review comments from Rui.
llvm-svn: 219179
|
|
|
|
|
|
|
|
| |
Teach the reader about ARM NT relocation types. Although the writer cannot yet
perform the actual application of these relocations, the reader can at least now
identify the relocation types.
llvm-svn: 219178
|
|
|
|
|
|
|
| |
These lines can be reachable if we give a broken or unsupported
input object file.
llvm-svn: 219176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we would not check the target machine type and the module (object)
machine type. Add a check to ensure that we do not attempt to use an object
file with a different target architecture.
This change identified a couple of tests which were incorrectly mixing up
architecture types, using x86 input for a x64 target. Adjust the tests
appropriately. The renaming of the input and the architectures covers the
changes to the existing tests.
One significant change to the existing tests is that the newly added test input
for x64 uses the correct user label prefix for X64.
llvm-svn: 219093
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to support more than x86/x86_64, we need to change the behaviour to use
the actual machine type rather than checking the bitness and assuming that we
are on X86. This replaces the use of is64bit in applyAllRelocations with a
check on the machine type. This will enable adding support for handling ARM
relocations.
Rename the existing applyRelocation methods to be similarly named and to make it
clear the types of relocations they will process.
llvm-svn: 219088
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change. This removes a down-cast from LinkingContext to
MachOLinkingContext.
Also, remove const from LinkingContext::createImplicitFiles() to remove
the need for another const cast. Seems reasonable for createImplicitFiles()
to need to modify the context (MachOLinkingContext does).
llvm-svn: 218796
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This is yet another edge case of ambiguous name resolution.
When a symbol is specified with /entry:SYM, SYM may be resolved
to the C++ mangled function name (?SYM@@YAXXZ).
llvm-svn: 218706
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 218705
|
|
|
|
|
|
|
|
| |
"__imp_" prefix always starts with double underscores.
When I was writing the original code I misunderstood
that it's "_imp_" on x64.
llvm-svn: 218690
|
|
|
|
|
|
|
|
| |
Previously we emit two or more identical definitions for an
exported symbol if the same /export option is given more than
once. This patch fixes that bug.
llvm-svn: 218433
|
|
|
|
|
|
|
|
|
|
|
|
| |
lib.exe prints a warning if a symbol in a module definition file has
both the PRIVATE attribute and an ordinal like this.
EXPORTS
foo @1 PRIVATE
This patch suppresses that.
llvm-svn: 218395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently you can omit the leading underscore from exported
symbol name. LLD will look for mangled name for you. But it won't
look for C++ mangled name.
This patch is to support that.
If "sym" is specified to be exported, the linker looks for not
only "sym", but also "_sym" and "?sym@@<whatever>", so that you
can export a C++ function without decorating it.
llvm-svn: 218355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exported symbol name resolution is two-pass. In the first pass,
we try to resolve that as a regular undefined symbol. If it fails,
we look for mangled name for the symbol and rename the undefined
symbol and try again.
After all name resolution is done, we look for an atom for each
exported symbol again, to construct the export table. In this
process we try the regular names first, and then try mangled names.
But at this moment we should have knew which name is correct.
This patch is to keep the information we get in the first process
to use it later.
llvm-svn: 218354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The export table descriptor is a data structure to keep information
about the export table. It contains a symbol name, and the name may
or may not be mangled.
We need unmangled names for the export table, so we demangle them
before writing them to the export table.
Obviously this is not a correct round-trip conversion. That could
drop a leading underscore from a symbol because that's
indistinguishable from a mangled name.
What we need to do is to keep unmangled names. This patch does that.
llvm-svn: 218345
|
|
|
|
|
|
|
|
| |
/machine:ebc was previously recognized but rejected. Unknown architecture
names were handled differently but eventually rejected too. We don't need
to distinguish them.
llvm-svn: 218344
|
|
|
|
|
|
|
|
|
| |
This patch changes the type of export table set from std::set to
std::vector. The new code is slightly inefficient, but because
export table elements are actually mutable, std::vector is better
here. No functionality change.
llvm-svn: 218343
|
|
|
|
|
|
|
|
|
| |
If two or more /export options are given for the same symbol, we should
always print a warning message and use the first one regardless of other
parameters.
Previously there was a case that the first parameter is not used.
llvm-svn: 218342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A symbol in a module definition file may be annotated with the
PRIVATE keyword like this.
EXPORTS
func PRIVATE
The PRIVATE keyword does not affect the resulting .dll file.
But it prevents the symbol to be listed in the .lib (import
library) file.
llvm-svn: 218273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Atoms are ordered in the output file by ordinal. File has file ordinal,
and atom has atom ordinal which is unique within the file.
No two atoms should have the same combination of ordinals.
However that contract was not satisifed for alias atoms. Alias atom
is defined by /alternatename:sym1=sym2. In this case sym1 is defined
as an alias for sym2. sym1 always got ordinal 0.
As a result LLD failed with an assertion failure.
This patch assigns ordinal to alias atoms.
llvm-svn: 218158
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cache the machine type value of the linking context. We need this in order to
calculate the virtual address of the atom when resolving function symbols.
Windows on ARM must check if the atom is a function and if so, set the Thumb bit
for the returned virtual address. Failure to do so will result in an abnormal
exit due to a trap caused by invalid instruction decoding. The same information
can be used to determine the relocation type that was previously being done via
is64 to select between x86 and x86_64.
llvm-svn: 218106
|
|
|
|
|
|
|
|
|
| |
Accept /machine:arm as an argument. This is changed to support ARM NT.
Although there is no way to differentiate between ARM (Windows CE) and ARM NT
(Windows on ARM), since LLVM currently only supports Windows on ARM, simply take
/machine:arm to mean Windows on ARM.
llvm-svn: 218105
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than saving whether we are targeting 64-bit x86 (x86_64), simply convert
the single use of that information to the actual relocation type. This will
permit the selection of non-x86 relocation types (e.g. for WoA support).
Inline the access of the machine type field as it is relatively cheap (a couple
of pointer dereferences) rather than storing the relocation type as a member
variable.
llvm-svn: 218104
|
|
|
|
|
|
|
|
| |
When we encounter an unknown machine type, we print out the machine type magic.
However, we would print out the magic in decimal rather than hex. Perform this
conversion to make it easier to identify what machine is unsupported.
llvm-svn: 218103
|
|
|
|
| |
llvm-svn: 218090
|
|
|
|
|
|
|
|
| |
I made LLD to report an error if /safeseh:no option is given on x64,
but it turned out MSVC link.exe doesn't report error on it.
Removing the check.
llvm-svn: 218077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The contents from section .CRT$XLA to .CRT$XLZ is an array of function
pointers. They are called by the runtime when a new thread is created
or (gracefully) terminated.
You can make your own initialization function to be called by that
mechanism. All you have to do is:
- Define a pointer to a function in a .CRT$XL* section using pragma
- Make an external reference to "__tls_used" symbol
That technique is used in many projects. This patch is to support that.
What this patch does is to set the relative virtual address of
"__tls_used" to the PECOFF directory table. __tls_used is actually a
struct containing pointers to a symbol in .CRT$XLA and another symbol
in .CRT$XLZ. The runtime looks at the directory table, gets the address
of the struct, and call the function pointers between XLA and XLZ.
llvm-svn: 218007
|
|
|
|
| |
llvm-svn: 217815
|
|
|
|
| |
llvm-svn: 217645
|
|
|
|
| |
llvm-svn: 217639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lld shouldn't directly use the COFF header nor should it use raw
coff_symbols. Instead, query the header properties from the
COFFObjectFile and use COFFSymbolRef to abstractly reference COFF
symbols.
This is just enough to get lld compiling with the changes to
llvm::object. Bigobj specific testing will come later.
Differential Revision: http://reviews.llvm.org/D5280
llvm-svn: 217497
|
|
|
|
| |
llvm-svn: 217219
|
|
|
|
| |
llvm-svn: 217121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I hope this is the last fix for x64 relocations as I've wasted
a few days on this.
This caused a mysterious issue that some C++ programs crash on
startup. It was because a null pointer is passed as argv to main.
__tmainCRTStartup calls main, but before that it calls all
initialization routines between .text$xc_a and .text$xc_z.
pre_cpp_init is one of such routines, and it is the one who
initializes a heap pointer for argv for later use. That routine
was not called for some reason.
It turned out that __tmainCRTStartup was skipping a block of
code because of the relocation bug. A condition in the function
depends on a memory load, and that memory load was referring
a wrong location. As a result a jump instruction took the
wrong branch, skipping pre_cpp_init and so on.
This patch fixes the issue. Also added more tests to fix them
once and for all.
llvm-svn: 216772
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
x86 and x64 are created equal -- taking x86 as the default argument
made it hard to find bugs.
llvm-svn: 216295
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 216152
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 216003
|
|
|
|
| |
llvm-svn: 214948
|
|
|
|
| |
llvm-svn: 214835
|