| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 208427
|
|
|
|
|
|
|
| |
I have a plan to use VirtualArchiveFile in this file in the near future.
This change should improve the readability by itself, too.
llvm-svn: 208365
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3599
llvm-svn: 207989
|
|
|
|
|
|
| |
This reverts commit r207884 which was prematurely committed by accident.
llvm-svn: 207886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isAlias always returns false and no one is using it. It was
originally added Atom to query if an atom is an alias for another
atom, assuming that alias atoms are different from normal atoms.
We now support atom aliasing, but the way that's implemented is
in a different way than what isAlias assumed. An alias atom is
just a regular defined atom with no content, and it has a layout-
before edge to alias-to atom so that they are layed out at the
same location in the result. So this is dead code, and it doesn't
make much sense to keep it.
llvm-svn: 207884
|
|
|
|
|
|
|
|
|
|
|
| |
Export definitions in a module definition file is as follows:
exportedname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]
Previously we did not support =internalname, so users couldn't export
symbols from a DLL with a different name.
llvm-svn: 207827
|
|
|
|
|
|
|
| |
You can omit @number suffix when specifying /export option,
but you can do that only for stdcall functions.
llvm-svn: 207809
|
|
|
|
| |
llvm-svn: 207802
|
|
|
|
|
|
| |
This is more efficient than before.
llvm-svn: 207791
|
|
|
|
|
|
|
|
| |
When creating a .lib file, we should strip the leading underscore,
but should not strip stdcall atsign suffix. Otherwise produced .lib
files cannot be linked.
llvm-svn: 207729
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the input file for the lib.exe command would be removed
as soon as the command exits, so we couldn't write a test to check
the file contents are correct.
This patch adds /lldmoduledeffile: option to retain a copy of the
temporary file at the given file path, so that you can see the file
if you want.
llvm-svn: 207727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linker should create _imp_ symbols for local use only when such
symbols cannot be resolved in any other way. If it overrides real
imported symbols, such symbols remain virtually unresolved without
error, causing odd issues. I observed that a program linked with
LLD entered an infinite loop before reaching main() because of
this issue.
This patch moves the virtual file creating _imp_ symbols to the
very end of the input file list. Previously, the file is at the end
of the library file group. Linker might revisit the group many times,
so it was not really at the end of the input file list.
llvm-svn: 207605
|
|
|
|
|
|
|
| |
You usually have to specify the exact name of a symbol to export it,
but for stdcall functions you can omit the @numbers suffix.
llvm-svn: 207491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit symbol for local use implemented in r207141 was not fully
compatible with MSVC link.exe. In r207141, I implemented the feature
in such way that implicit symbols are defined only when they are
exported with /EXPORT option.
After that I found that implicit symbols are defined not only for
dllexported symbols but for all defined symbols. Actually _imp_
implicit symbols have no relationship with the dllexport feature. You
could add _imp_ to any symbol to get a pointer to the symbol, whether
the symbol is dllexported or not. It looks pretty weird to me but
that's what we want if link.exe behaves that way.
Here is a bit about the implementation: Creating all implicit symbols
beforehand is going to be a huge waste of resource. This feature is
rarely used, and MSVC link.exe even prints out a warning message when
it finds this feature is being used. So we create implicit symbols
on demand. There is an archive file that creates implicit symbols when
they are needed.
llvm-svn: 207476
|
|
|
|
|
|
| |
This option is to override the default import file path.
llvm-svn: 207175
|
|
|
|
| |
llvm-svn: 207168
|
|
|
|
| |
llvm-svn: 207154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is to fix a compatibility issue with MSVC link.exe as to
use of dllexported symbols inside DLL.
A DLL exports two symbols for a function. One is non-decorated one,
and the other is with __imp_ prefix. The former is a function that
you can directly call, and the latter is a pointer to the function.
These dllexported symbols are created by linker for programs that
link against the DLL. So, I naturally believed that __imp_ symbols
become available when you once create a DLL and link against it, but
they don't exist until then. And that's not true.
MSVC link.exe is smart enough to allow users to use __imp_ symbols
locally. That is, if a symbol is specified with /export option, it
implicitly creates a new symbol with __imp_ prefix as a pointer to
the exported symbol. This feature allows the following program to
be linked and run, although _imp__hello is not defined in this code.
#include <stdio.h>
__declspec(dllexport)
void hello(void) { printf("Hello\n"); }
extern void (*_imp__hello)(void);
int main() {
_imp__hello();
return 0;
}
MSVC link.exe prints out the following warning when linking it.
LNK4217: locally defined symbol _hello imported in function _main
Using __imp_ symbols locally is I think not a good coding style. One
should just take an address using "&" operator rather than appending
__imp_ prefix. However, there are programs in the wild that depends
on this link.exe's behavior, so we need this feature.
llvm-svn: 207141
|
|
|
|
|
|
|
|
| |
Not all symbols are decorated with an underscore in x86. You can
write undecorated symbols in assembly, for example. Thus this
assertion is too strong.
llvm-svn: 207125
|
|
|
|
|
|
|
|
|
| |
We don't use sections with IMAGE_SYM_DEBUG attribute so we basically
want to the symbols for them when reading symbol table. When we skip
them, we need to skip auxiliary symbols too. Otherwise weird error
would happen because aux symbols would be interpreted as regular ones.
llvm-svn: 206931
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3322
llvm-svn: 205826
|
|
|
|
|
|
|
|
|
| |
Seems getSomething() is more common naming scheme than just a noun
to get something, so renaming these members.
Differential Revision: http://llvm-reviews.chandlerc.com/D3285
llvm-svn: 205589
|
|
|
|
|
|
|
|
|
| |
"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
|
|
|
|
|
|
|
| |
insertElementsAt() is removed, so "One" in insertOneElementAt() no longer
make much sense. Rename it for brevity.
llvm-svn: 205372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is to support --defsym option for ELF file format/GNU-compatible
driver. Currently it takes a symbol name followed by '=' and a number. If such
option is given, the driver sets up an absolute symbol with the specified
address. You can specify multiple --defsym options to define multiple symbols.
GNU LD's --defsym provides many more features. For example, it allows users to
specify another symbol name instead of a number to define a symbol alias, or it
even allows a symbol plus an offset (e.g. --defsym=foo+3) to define symbol-
relative alias. This patch does not support that, but will be supported in
subsequent patches.
Differential Revision: http://llvm-reviews.chandlerc.com/D3208
llvm-svn: 205029
|
|
|
|
| |
llvm-svn: 204223
|
|
|
|
|
|
|
|
|
|
| |
COMDAT_SELECT_LARGEST is a COMDAT type that make linker to choose the largest
definition from among all of the definition of a symbol. If the size is the
same, the choice is arbitrary.
Differential Revision: http://llvm-reviews.chandlerc.com/D3011
llvm-svn: 204172
|
|
|
|
| |
llvm-svn: 204122
|
|
|
|
|
|
| |
So we don't need static_cast's to convert it from signed to unsigned.
llvm-svn: 203992
|
|
|
|
|
|
|
| |
The COFF spec says that the SectionNumber field in the symbol table is 16 bit
signed type, but MSVC treats the field as if it is unsigned.
llvm-svn: 203901
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
An object whose machine type header value is unknown looks a bit odd but
is valid. If an object contains only machine-type-independent data, you
can leave the type field unspecified. Some files in oldname.lib are such
object files.
llvm-svn: 203752
|
|
|
|
| |
llvm-svn: 203666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
COMDAT_SELECT_SAME_SIZE is a COMDAT type that I presume exist only in COFF.
The semantics of the type is that linker should merge such COMDAT sections if
their sizes are the same. Otherwise it's an error.
Reviewers: Bigcheese, shankarke, kledzik
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2996
llvm-svn: 203308
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202645
|
|
|
|
|
|
| |
requiring MSVC 2012 or newer.
llvm-svn: 202626
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202217
|
|
|
|
|
|
| |
IMAGE_DLL_CHARACTERISTICS_NO_SEH flag should be set only when SEH is disabled.
llvm-svn: 202215
|
|
|
|
| |
llvm-svn: 202113
|
|
|
|
|
|
|
|
| |
This restores the debug output to how it was before r197727 broke it. This
went undetected because the corresponding test was never run due to broken
feature detection.
llvm-svn: 202079
|
|
|
|
| |
llvm-svn: 201970
|
|
|
|
|
|
|
| |
LLD now prints an error message if /SAFESEH option is specified and one or
more input files are not compatible with SEH.
llvm-svn: 201900
|
|
|
|
| |
llvm-svn: 201109
|