| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts accidental commit r208427.
llvm-svn: 208433
|
|
|
|
| |
llvm-svn: 208428
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Previously only GNU driver calls InputGraph::normalize, but its
functionality is not and should not be limited to GNU ld. Other
driver should be able to use it.
Currently only linker scripts use the feature, so this change
won't change the existing behavior.
llvm-svn: 208266
|
|
|
|
| |
llvm-svn: 208256
|
|
|
|
| |
llvm-svn: 208145
|
|
|
|
|
|
|
|
| |
Previously only the toplevel elements were expanded by expandElements().
Now we recursively call getReplacements() to expand input elements even
if they are in, say, in a group.
llvm-svn: 208144
|
|
|
|
|
|
|
| |
addInputElement() never fails, and no one checks its return value
except tests. Let's simplify the signature.
llvm-svn: 208109
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3599
llvm-svn: 207989
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 207953
|
|
|
|
| |
llvm-svn: 207949
|
|
|
|
|
|
| |
This reverts commit r207884 which was prematurely committed by accident.
llvm-svn: 207886
|
|
|
|
| |
llvm-svn: 207885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207878
|
|
|
|
| |
llvm-svn: 207875
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207821
|
|
|
|
|
|
|
| |
You can omit @number suffix when specifying /export option,
but you can do that only for stdcall functions.
llvm-svn: 207809
|
|
|
|
| |
llvm-svn: 207802
|
|
|
|
| |
llvm-svn: 207798
|
|
|
|
|
|
| |
This is more efficient than before.
llvm-svn: 207791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
element is a FileNode, request error description. If the element is Group,
print hard coded error message. We need to implement a better diagnostics
here but even current solution is better than a segmentation fault output.
llvm-svn: 207691
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 207690
|
|
|
|
|
|
|
|
| |
into the separate function.
No functional changes.
llvm-svn: 207689
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 207688
|
|
|
|
| |
llvm-svn: 207687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207495
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207493
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207435
|
|
|
|
|
|
| |
member functions.
llvm-svn: 207434
|
|
|
|
|
|
|
|
| |
I'm a bit surprised that I have not implemented this yet. This is
definitely needed to handle real-world module definition files.
This patch contains a unit test for r207294.
llvm-svn: 207297
|
|
|
|
|
|
|
|
| |
I'm fixing another bug in the parser, and I wanted to submit this
fix as a separate change as it's logically independent from the other.
I'll add a test for this shortly.
llvm-svn: 207294
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Previously LLD would fail if /OPT:icf, /OPT:lbr or such are specified,
because these command line flags would be handled as unknown ones. We
rather want LLD to ignore these known but yet-to-be-implemented options
for now.
Added tests for the driver as well.
llvm-svn: 206863
|