/alternatename is a command line option to define a weak alias. You
can use it as /alternatename:foo=bar to define "foo" as a weak alias
for "bar".
Because it's a command line option, the weak alias mapping is in the
LinkingContext object, and not in a object file being read.
Previously, we looked up the mapping each time we read a new symbol
from a file, to check if there is a weak alias defined for the symbol.
That's not wrong, but had made function signature's a bit complicated --
we had to pass the mapping object to many functions. Now their
parameter lists are much cleaner.
This also has another (unrealized) benefit. parseFile() now read a
file and then add alias symbols to the file. In the first pass a
LinkingContext object is not used at all. That should make it easy
to read files from archive files speculatively, as the first pass
is free from side effect.
llvm-svn: 209486
In r205566, I made a change to Resolver so that Resolver revisit
only archive files in --start-group and --end-group pair. That's
not correct, as it also has to revisit DSO files.
This patch is to fix the issue.
Added a test to demonstrate the fix. I confirmed that it succeeded
before r205566, failed after r205566, and is ok with this patch.
Differential Revision: http://reviews.llvm.org/D3734
llvm-svn: 208797
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
If one or more dynamic relocation might modify a read-only section,
dynamic table should contain DT_TEXTREL tag.
The patch introduces new `RelocationTable::canModifyReadonlySection()`
method. This method checks through the relocations to see if any modifies
a read-only section. The DynamicTable class calls this method and emits
the DT_TEXTREL tag if necessary.
The patch reviewed by Rui Ueyama and Shankar Easwaran.
llvm-svn: 208670
We did not actively try to resolve dllexported symbols specified
by /export or by a module definition file. So if exported symbols
would be resolved for other reasons, like other symbols refer to
them, that was fine, but if (unreferenced) exported symbols were
in an archive file, and no one refers to that file in the archive,
they remained unresolved.
That would obviously cause the issue that dllexported symbols are
not in a resultant DLL.
In this patch, we create an undefined symbol for each dllexported
symbol, to let the core linker to resolve it.
llvm-svn: 208452
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
In general the linker scripts's GROUP command works like a pair
of command line options --start-group/--end-group. But there is
a difference in the files look up algorithm.
The --start-group/--end-group commands use a trivial approach:
a) If the path has '-l' prefix, add 'lib' prefix and '.a'/'.so'
suffix and search the path through library search directories.
b) Otherwise, use the path 'as-is'.
The GROUP command implements more compicated approach:
a) If the path has '-l' prefix, add 'lib' prefix and '.a'/'.so'
suffix and search the path through library search directories.
b) If the path does not have '-l' prefix, and sysroot is configured,
and the path starts with the / character, and the script being
processed is located inside the sysroot, search the path under
the sysroot. Otherwise, try to open the path in the current
directory. If it is not found, search through library search
directories.
https://www.sourceware.org/binutils/docs-2.24/ld/File-Commands.html
The patch reviewed by Shankar Easwaran, Rui Ueyama.
llvm-svn: 207769
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
1. Re-implement PLT entries and dynamic relocations emitting to keep PLT
and relocations table in a consistent state.
2. Initialize st_value and st_other fields for dynamic symbols table
entry if this entry corresponds to an external function which address is
taken in a non-PIC executable. In that case the st_value field holds an
address of the function's PLT entry. Also set STO_MIPS_PLT bit in the
st_other field.
llvm-svn: 207494
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
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
LIBRARY directive in a module definition file specifies the output
DLL file name. It also takes an optional value for the base address.
llvm-svn: 206647
Currently LLD supports --defsym only in the form of
--defsym=<symbol>=<integer>, where the integer is interpreted as the
absolute address of the symbol. This patch extends it to allow other
symbol name to be given as an RHS value. If a RHS value is a symbol
name, the LHS symbol will be defined as an alias for the RHS symbol.
Internally, a LHS symbol is represented as a zero-size defined atom
who has an LayoutAfter reference to an undefined atom, whose name is
the RHS value. Everything else is already implemented -- Resolver
will resolve the undefined symbol, and the layout pass will layout
the two atoms at the same location. Looks like it's working fine.
Note that GNU LD supports --defsym=<symbol>=<symbol>+<addend>. That
feature is out of scope of this patch.
Differential Revision: http://reviews.llvm.org/D3332
llvm-svn: 206417
a couple of new virtual functions.
Follow-up to the rL203408. Two virtual functions `createRelocationReference()`
responsible for creation of `ELFReference` have been replaced by a couple of
new virtual functions `createRelocationReferences()` (plural). Each former
function creates a //single// ELFReference for a specified `Elf_Rela`
or `Elf_Rel` relocation records. The new functions responsible for creation
of //all// relocation references for provided symbol.
For all targets except MIPS there are no functional changes.
MIPS ABI has a notion of //paired// relocations. An effective addend of such
relocations are calculated using addends of both pair's members.
Each `R_MIPS_HI16` and `R_MIPS_GOT16` (for local symbols) relocations must have
an associated `R_MIPS_LO16` entry immediately following it in the list
of relocations. Immediately does not mean "next record" in relocations section
but "next record referenced the same symbol". Moreover a single `R_MIPS_LO16`
relocation can be paired with multiple preceding `R_MIPS_HI16/R_MIPS_GOT16`
relocations.
The paired relocation can have offsets belong to the different symbols.
That is why we need to have access to list of all relocations during
construction of `ELFReference` for MIPS target.
The patch reviewed by Shankar Easwaran.
llvm-svn: 206102
Rui Ueyama