| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/INCLUDE arguments passed as command line options are handled in the
same way as Unix -u. All option values are converted to an undefined
symbol and added to a dummy input file, so that the specified symbols
are resolved.
One tricky thing on Windows is that the option is also allowed to
appear in the object file's directive section. At the time when
it's being read, all (regular) command line options have already
been processed. We cannot add undefined atoms to the dummy file
anymore.
Previously, we added such /INCLUDE to a set that has already been
processed. As a result the options were ignored.
This patch fixes the issue. Now, /INCLUDE symbols in the directive
section are handled as real undefined symbol in the COFF file.
We create an undefined symbol for each /INCLUDE argument and add
it to the file being parsed.
llvm-svn: 214824
|
|
|
|
| |
llvm-svn: 214791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PE/COFF spec says that SizeOfRawData field in the section
header must be a multiple of FileAlignment from the optional
header. LLD emits 512 as FileAlignment, so it must have been
a multiple of 512.
LLD did not follow that. It emitted the actual section size
without the last padding as the SizeOfRawData. Although it's
not correct as per the spec, the Windows loader doesn't seem
to actually bother to check that. Executables created by LLD
worked fine.
However, tools dealing with executalbe files may expect it
to be the correct value, and one instance of it is mt.exe
tool distributed as a part of Windows SDK.
If CMake is invoked with "-E vs_link_exe" option, it silently
run mt.exe to embed a resource file to the resulting file.
And mt.exe sometimes breaks an input file if it's section
header does not follow the standard. That caused a misterous
error that CMake with Ninja occasionally produces a broken
executable.
This patch fixes the section header to make mt.exe and
other tools happy.
llvm-svn: 214453
|
|
|
|
| |
llvm-svn: 214378
|
|
|
|
|
|
| |
insertElementAt(x, END) is the same as addInputElement(x).
llvm-svn: 213818
|
|
|
|
|
|
|
|
|
| |
The entry point file needs to be processed after all other
object files and before all .lib files. It was processed
after .lib files. That caused an issue that the entry point
function was not resolved from the standard library files.
llvm-svn: 213804
|
|
|
|
|
|
|
| |
Because of a bug, the entry point address in the PE/COFF header
was not correct.
llvm-svn: 213802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows there are four "main" functions -- main, wmain, WinMain,
or wWinMain. Their parameter types are diffferent. The standard
library provides four different entry functions (i.e.
{w,}{WinMain,main}CRTStartup) for them. You need to use the right
entry routine for your "main" function.
If you give an /entry option, the specified name is used
unconditionally.
Otherwise, the linker needs to select the right one based on
user-supplied entry point function. This can be done after the
linker reads all the input files.
This patch moves the code to determine the entry point function
from the driver to a virtual input file. It also implements the
correct logic for the entry point function selection.
llvm-svn: 213713
|
|
|
|
|
|
| |
So that it can be shared by multiple input files.
llvm-svn: 213699
|
|
|
|
| |
llvm-svn: 213560
|
|
|
|
|
|
|
|
|
| |
The code to manage resolvable symbols is now separated from
ExportedSymbolRenameFile so that other class can reuse it.
I'm planning to use it to find the entry function symbol
based on resolvable symbols.
llvm-svn: 213322
|
|
|
|
| |
llvm-svn: 213312
|
|
|
|
|
|
|
| |
Windows loader can load a DLL without this bit but it wouldn't
call the initializer function in the DLL if the bit is absent.
llvm-svn: 213216
|
|
|
|
|
|
|
| |
The resource table entry should have the RVA of the
embedded resource file.
llvm-svn: 212765
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we invoked cvtres.exe for each compiled Windows
resource file. The generated files were then concatenated
and embedded to the executable.
That was not the correct way to merge compiled Windows
resource files. If you just concatenate generated files,
only the first file would be recognized and the rest would
be ignored as trailing garbage.
The right way to merge them is to call cvtres.exe with
multiple input files. In this patch we do that in the
Windows driver.
llvm-svn: 212763
|
|
|
|
|
|
|
|
|
|
| |
Previously the alignment of the .bss section was not
properly set because of a bug in AtomizeDefinedSymbolsInSection.
We set the alignment of the section at the end of the function,
but we use an eraly return for the .bss section, so the code had
been skipped.
llvm-svn: 212571
|
|
|
|
| |
llvm-svn: 212407
|
|
|
|
| |
llvm-svn: 211548
|
|
|
|
|
|
| |
A refactoring, with the added benefit of helping OS X builds.
llvm-svn: 211371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF supports a feature similar to ELF's section groups. This
patch implements it.
In ELF, section groups are identified by their names, and they are
treated somewhat differently from regular symbols. In COFF, the
feature is realized in a more straightforward way. A section can
have an annotation saying "if Nth section is linked, link this
section too."
I added a new reference type, kindAssociate. If a target atom is
coalesced away, the referring atom is removed by Resolver, so that
they are treated as a group.
Differential Revision: http://reviews.llvm.org/D4028
llvm-svn: 211106
|
|
|
|
| |
llvm-svn: 210919
|
|
|
|
| |
llvm-svn: 210878
|
|
|
|
| |
llvm-svn: 210831
|
|
|
|
| |
llvm-svn: 210801
|
|
|
|
|
|
| |
This will reduce the noise in a followup patch.
llvm-svn: 210800
|
|
|
|
| |
llvm-svn: 210785
|
|
|
|
|
|
|
|
| |
Because the files in Core actually depend on these files.
Differential Revision: http://reviews.llvm.org/D4000
llvm-svn: 210710
|
|
|
|
|
|
| |
This is an update for a llvm api change.
llvm-svn: 210689
|
|
|
|
| |
llvm-svn: 210621
|
|
|
|
|
|
| |
This reverts accidental commit r210240.
llvm-svn: 210243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF supports a feature similar to ELF's section groups. This
patch implements it.
In ELF, section groups are identified by their names, and they are
treated somewhat differently from regular symbols. In COFF, the
feature is realized in a more straightforward way. A section can
have an annotation saying "if Nth section is linked, link this
section too."
Implementing such feature is easy. We can add a reference from a
target atom to an original atom, so that if the target is linked,
the original atom is also linked. If not linked, both will be
dead-stripped. So they are treated as a group.
I added a new reference type, kindAssociate. It does nothing except
preventing referenced atoms from being dead-stripped.
No change to the Resolver is needed.
Reviewers: Bigcheese, shankarke, atanasyan
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3946
llvm-svn: 210240
|
|
|
|
|
|
|
|
| |
This provides support for the autoconfing & make build style.
The format, style and implementation follows that used within the llvm and clang projects.
TODO: implement out-of-source documentation builds.
llvm-svn: 210177
|
|
|
|
|
|
|
| |
Previously the parser always printed out an error message followed
by "Invalid file type" even if the file type is correct.
llvm-svn: 210093
|
|
|
|
| |
llvm-svn: 210015
|
|
|
|
| |
llvm-svn: 210014
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209948
|
|
|
|
| |
llvm-svn: 209497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/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
|
|
|
|
| |
llvm-svn: 209323
|
|
|
|
| |
llvm-svn: 209317
|
|
|
|
| |
llvm-svn: 209274
|
|
|
|
| |
llvm-svn: 209271
|
|
|
|
|
|
|
|
|
|
|
| |
addResolvableSymbols() queues input files, and readAllSymbols() reads
from them. In practice it's currently safe because they are called from
a single thread. But it's not guaranteed.
Also, acquiring the same mutex is needed not to see inconsistent memory
contents that is allowed in the C++ memory model.
llvm-svn: 209254
|
|
|
|
| |
llvm-svn: 209243
|
|
|
|
| |
llvm-svn: 209213
|
|
|
|
|
|
|
|
| |
ExportedSymbolRenameFile is not always used. In most cases we don't
need to read given files at all. So lazy load would help. This doesn't
change the meaining of the program.
llvm-svn: 208818
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|