Looks like the rule of /export is more complicated than
I was thinking. If /export:foo, for example, is given, and
if the actual symbol name in an object file is _foo@<number>,
we need to export that symbol as foo, not as the mangled name.
If only /export:_foo@<number> is given, the symbol is exported
as _foo@<number>.
If both /export:foo and /export:_foo@<number> are given,
they are considered as duplicates, and the linker needs to
choose the unmangled name.
The basic idea seems that the linker needs to export a symbol
with the same name as given as /export.
We exported mangled symbols. This patch fixes that issue.
llvm-svn: 223341
/export option can be given multiple times to specify multiple
symbols to be exported. /export accepts both decorated and
undecorated name.
If you give both undecorated and decorated name of the same symbol
to /export, they are resolved to the same symbol. In this case,
we need to de-duplicate the exported names, so that we don't have
duplicated items in the export symbol table in a DLL.
We remove duplicate items from a vector. The bug was there.
Because we had pointers pointing to elements of the vector,
after an item is removed, they would point wrong elements.
This patch is to remove these pointers. Added a test for that case.
llvm-svn: 223200
Export table entries need to be sorted in ASCII-betical order,
so that the loader can find an entry for a function by binary search.
We sorted the entries by its mangled names. That can be different
from their exported names. As a result, LLD produces incorrect export
table, from which the loader complains that a function that actually
exists in a DLL cannot be found.
This patch fixes that issue.
llvm-svn: 222452
This is a follow-up patch for r220333. r220333 renames exported symbols.
That raised another issue; if we have both decorated and undecorated names
for the same symbol, we'll end up have two duplicate exported symbol
entries.
This is a fix for that issue by removing duplciate entries.
llvm-svn: 220350
There are two ways to specify a symbol to be exported in the module
definition file.
1) EXPORT <external name> = <symbol>
2) EXPORT <symbol>
In (1), you give both external name and internal name. In that case,
the linker tries to find a symbol using the internal name, and write
that address to the export table with the external name. Thus, from
the outer world, the symbol seems to be exported as the external name.
In (2), internal name is basically the same as the external name
with an exception: if you give an undecorated symbol to the EXPORT
directive, and if the linker finds a decorated symbol, the external
name for the symbol will become the decorated symbol.
LLD didn't implement that exception correctly. This patch fixes that.
llvm-svn: 220333
MSDN doesn't say about /export:foo=bar style option, but
it turned out MSVC link.exe actually accepts that. So we need that
too.
It also means that the export directive in the module definition
file and /export command line option are functionally equivalent.
llvm-svn: 218695
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
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
As written in the comment in this patch, symbol names specified with
/export option is resolved in a special way; for /export:foo, linker
finds a foo@<number> symbol if such symbols exists.
On Windows, a function in stdcall calling convention is mangled with
a leading underscore and following "@" and numbers. This name
mangling is kind of automatic, so you can sometimes omit _ and @number
when specifying a symbol. /export option is that case.
Previously, if a file in an archive file foo.lib provides a symbol
_fn@8, and /export:fn is specified, LLD failed to resolve the symbol.
It only tried to find _fn, and failed to find _fn@8. With this patch,
_fn@8 will be searched on the second iteration.
Differential Revision: http://reviews.llvm.org/D3736
llvm-svn: 208754
Previously the handling of exported symbol was wrong if it's
specified in a module definition file in the form of
<externalname>=<internalname>. Export the correct symbol.
llvm-svn: 208446
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
Module-definition (.def) files are the file containing linker directives,
such as export symbols. Because link.exe supports the same features as command
line options, just as some Linker Script commands overlaps with command line
options, use of module-definition file is not really necessary. It provides
an alternative way to specify some linker options.
This patch implements EXPORTS directive. Other directives will be implemented
in the future.
llvm-svn: 198925
There was a bug that the linker does not report an error if symbols specified
by -u (or /include on Windows) are not resolved. This patch fixes it by adding
such symbols to the dead strip root.
llvm-svn: 198041
Subsystem field in the PE/COFF file header has no meanining for the DLL.
It looks like MSVC link.exe sets the default subsystem (Windows GUI) to
the field if no /subsystem option is specified.
llvm-svn: 198015
If NONAME option is given for an export, that symbol will be exported only by
its ordinal. LLD will not emit the symbol name to the export table.
llvm-svn: 197371
OrdinalBase is an addend to the ordinals. We used to always set 1 to the field.
Although it produced a valid a DLL export table, it'd be a waste if the first
ordinal does not start with 1 -- we had to have NULL fields at the beginning of
the export address table. By setting the ordinal base, we can eliminate the
NULL fields.
llvm-svn: 197367
You can specify exported function's ordinal by /export:func,@<number> command
line option, but LLD ignored the option until now. This patch implements the
feature.
Ordinal is basically the index into the exported function address table. So,
for example, if /export:foo,@42 is specified, the linker writes foo's address
to 42th entry in the address table. Windows supports import-by-ordinal; you
can not only import a function by name, but by its ordinal. If you want to
allow your DLL users to import your functions by their ordinals, you need to
make sure that your functions are always exported with the same ordinals.
This is the feature for that situation.
llvm-svn: 197364
The only data in .edata whose length varies is the string. This patch moves
all the strings to the end of the section, so that 16-bit or 32-bit integers
are aligned on correct boundaries.
llvm-svn: 197213
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
Rui Ueyama