| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
The darwin linker has two ways to force all members of an archive to be loaded.
The -all_load option applies to all static libraries. The -force_load takes
a path to a library and just that library's members are force loaded.
llvm-svn: 221477
|
|
|
|
|
|
|
|
|
|
|
|
| |
The darwin linker does not process dwarf debug info. Instead it produces a
"debug map" in the output file which points back to the original .o files for
anything that wants debug info (e.g. debugger).
The -S option means "don't add a debug map". lld for mach-o currently does
not generate the debug map, so there is nothing to do when this option is used.
But we need to process the option to get existing projects building.
llvm-svn: 221432
|
|
|
|
| |
llvm-svn: 221414
|
|
|
|
| |
llvm-svn: 221257
|
|
|
|
|
|
| |
To be more compatible with existing darwin linker.
llvm-svn: 220822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The darwin linker operates differently than the gnu linker with respect to
libraries. The darwin linker first links in all object files from the command
line, then to resolve any remaining undefines, it repeatedly iterates over
libraries on the command line until either all undefines are resolved or no
undefines were resolved in the last pass.
When Shankar made the InputGraph model, the plan for darwin was for the darwin
driver to place all libraries in a group at the end of the InputGraph. Thus
making the darwin model a subset of the gnu model. But it turns out that does
not work because the driver cannot tell if a file is an object or library until
it has been loaded, which happens later.
This solution is to subclass InputGraph for darwin and just iterate the graph
the way darwin linker needs.
llvm-svn: 220330
|
|
|
|
|
|
| |
The -mllvm option is not specific to LTO.
llvm-svn: 220263
|
|
|
|
|
|
|
| |
This adds functionality in the GNU flavor to demangle symbols when
undefined symbols are displayed to the user.
llvm-svn: 220184
|
|
|
|
| |
llvm-svn: 220131
|
|
|
|
|
|
|
| |
target_link_libraries. [PR20254]
FIXME: Dependencies should be reorganized.
llvm-svn: 220000
|
|
|
|
|
|
|
|
|
|
|
| |
-all_load tells the darwin linker to immediately load all members of all
archives. The code do that used reinterpret_cast<> instead of dyn_cast<>.
If the file was a dylib, the reinterpret_cast<> turned a pointer to a dylib
into a pointer to an archive...boom.
Added test case to reproduce the crash, simplified the code and used dyn_cast<>.
llvm-svn: 219990
|
|
|
|
|
|
|
|
| |
To deal with cycles in shared library dependencies, the darwin linker supports
marking specific link dependencies as "upward". An upward link is when a
lower level library links against a higher level library.
llvm-svn: 219949
|
|
|
|
|
|
|
|
|
|
| |
This patch creates the import address table and sets its
address to the delay-load import table. This also creates
wrapper functions for __delayLoadHelper2.
x86 only for now.
llvm-svn: 219948
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial patch to emit the delay-import table. With this,
LLD is now able to emit the table that llvm-readobj can read and
dump.
The table lacks a few fields, such as the address of HMODULE, the
import address table, etc. They'll be added in subsequent patches.
llvm-svn: 219384
|
|
|
|
|
|
| |
This is a step toward full support of /delayload.
llvm-svn: 219344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a dynamic executable and receiving the -E flag, the linker should
export all globally visible symbols in its dynamic symbol table.
This commit also moves the logic that exports symbols in the dynamic symbol
table from OutputELFWriter to the ExecutableWriter class. It is not correct to
leave this at OutputELFWriter because DynamicLibraryWriter, another subclass of
OutputELFWriter, already exports all symbols, meaning we can potentially end up
with duplicated symbols in the dynamic symbol table when creating shared libs.
Reviewers: shankarke
http://reviews.llvm.org/D5585
llvm-svn: 219334
|
|
|
|
| |
llvm-svn: 219326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add support in the universal driver to print the lld version and the
repository version.
Test Plan: A driver test is added
Reviewers: kledzik, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D5641
llvm-svn: 219277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files (or archives of mach-o files) built for
different architectures. Previously, the support for fat files was in the
MachOReader, but that only supported fat .o files and dylibs (not archives).
The fix is to put the fat handing into MachOFileNode. That way any input file
kind (including archives) can be fat. MachOFileNode selects the sub-range
of the fat file that matches the arch being linked and creates a MemoryBuffer
for just that subrange.
llvm-svn: 219268
|
|
|
|
|
|
|
| |
If /machine option is omitted, the linker needs to infer that from
input object files. This patch implements that.
llvm-svn: 219180
|
|
|
|
| |
llvm-svn: 219041
|
|
|
|
|
|
|
|
|
|
|
| |
This option is added by Xcode when it runs the linker. It produces a binary
file which contains the file the linker used. Xcode uses the info to
dynamically update it dependency tracking.
To check the content of the binary file, the test case uses a python script
to dump the binary file as text which FileCheck can check.
llvm-svn: 219039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DLL delay importing is a feature to load a DLL lazily, instead of
at program start-up time.
If the feature is turned on with the /delayload flag, the linker
resolves the delay-load helper function. All function pointer table
entries for the DLL are initially pointing to the helper function.
When called, the function loads and resolves the DLL symbols using
dlopen-ish Windows system calls and then write the reuslts to the
function pointer table. The helper function is in "delayimp.lib".
Note that this feature is not completely implemented yet. LLD
also needs to emit the table that's consumed by the delay-load
helper function. That'll be done in another patch.
llvm-svn: 218943
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change. This removes a down-cast from LinkingContext to
MachOLinkingContext.
Also, remove const from LinkingContext::createImplicitFiles() to remove
the need for another const cast. Seems reasonable for createImplicitFiles()
to need to modify the context (MachOLinkingContext does).
llvm-svn: 218796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The darwin linker has the -demangle option which directs it to demangle C++
(and soon Swift) mangled symbol names. Long term we need some Diagnostics object
for formatting errors and warnings. But for now we have the Core linker just
writing messages to llvm::errs(). So, to enable demangling, I changed the
Resolver to call a LinkingContext method on the symbol name.
To make this more interesting, the demangling code is done via __cxa_demangle()
which is part of the C++ ABI, which is only supported on some platforms, so I
had to conditionalize the code with the config generated HAVE_CXXABI_H.
llvm-svn: 218718
|
|
|
|
|
|
| |
PRIVATE option is also an undocumented feature.
llvm-svn: 218696
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Move method implementation from header file to .cpp file. No functionality
change.
llvm-svn: 218639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The export table descriptor is a data structure to keep information
about the export table. It contains a symbol name, and the name may
or may not be mangled.
We need unmangled names for the export table, so we demangle them
before writing them to the export table.
Obviously this is not a correct round-trip conversion. That could
drop a leading underscore from a symbol because that's
indistinguishable from a mangled name.
What we need to do is to keep unmangled names. This patch does that.
llvm-svn: 218345
|
|
|
|
|
|
|
|
| |
/machine:ebc was previously recognized but rejected. Unknown architecture
names were handled differently but eventually rejected too. We don't need
to distinguish them.
llvm-svn: 218344
|
|
|
|
|
|
|
|
|
| |
Also allows -core/flavor to appear at any position in the command line.
Patch from Oleg Ranevskyy!
http://reviews.llvm.org/D5384
llvm-svn: 218321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A symbol in a module definition file may be annotated with the
PRIVATE keyword like this.
EXPORTS
func PRIVATE
The PRIVATE keyword does not affect the resulting .dll file.
But it prevents the symbol to be listed in the .lib (import
library) file.
llvm-svn: 218273
|
|
|
|
|
|
|
|
|
| |
Accept /machine:arm as an argument. This is changed to support ARM NT.
Although there is no way to differentiate between ARM (Windows CE) and ARM NT
(Windows on ARM), since LLVM currently only supports Windows on ARM, simply take
/machine:arm to mean Windows on ARM.
llvm-svn: 218105
|
|
|
|
|
|
|
|
|
| |
LLVM coding style says that "static" is preferred for file-scope
functions.
Differential Revision: http://reviews.llvm.org/D5323
llvm-svn: 217692
|
|
|
|
|
|
| |
This matches the strtoull() behavior in ld64.
llvm-svn: 217650
|
|
|
|
| |
llvm-svn: 217578
|
|
|
|
|
|
|
|
|
| |
The provided base must also be a multiple of the system's page size, which is a
reasonable enough demand.
Also check the other diagnostics more thoroughly.
llvm-svn: 217577
|
|
|
|
|
|
|
| |
Because NO LINKER MAY CHANGE. EVER. Even if it's a complete rewrite
from scratch.
llvm-svn: 217572
|
|
|
|
|
|
|
| |
The dangling "else" at the end of #if looked a bit error-prone.
Make it a separate function. No functionality change.
llvm-svn: 217568
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing system linkers on Darwin and Linux are called "ld". We'd like to
eventually drop in lld as "ld" and have it just work. But lld is a universal
linker that requires the first option to be -flavor to know which command line
mode to emulate (gnu or darwin).
This change tests if argv[0] is "ld" and if so, if the tool was built on MacOSX
then assume the darwin flavor otherwise the gnu flavor. There are two test
cases which copy lld to "ld" and then run it. One for darwin and one for linux.
llvm-svn: 217566
|
|
|
|
|
|
| |
This keeps non-conformant MSVC implementations happy.
llvm-svn: 217491
|
|
|
|
|
|
|
| |
As suggested by Nick, this will make __unwind_info implementation more natural,
and it'd have to be done at some point anyway.
llvm-svn: 217486
|
|
|
|
| |
llvm-svn: 217411
|
|
|
|
| |
llvm-svn: 217409
|
|
|
|
|
|
|
|
|
| |
There is a bit (MH_PIE) in the flags field of the mach_header which tells
the kernel is a program was built position independent (for ASLR). The linker
automatically attempts to build programs PIE if they are built for a recent
OS version. But the -pie and -no_pie options override that default behavior.
llvm-svn: 217408
|
|
|
|
|
|
|
|
|
|
| |
When a file is not found, produce a proper error message. The previous error
message produced a file format error, which made me wonder for a while why
there is a file format error, but essentially the file was not found.
This fixes the problem by producing a proper error message.
llvm-svn: 217359
|
|
|
|
|
|
|
|
|
| |
By default linker would not create a separate segment to hold read only data.
This option overrides that behavior by creating the a separate read only segment
for read only data.
llvm-svn: 217358
|
|
|
|
|
|
|
| |
When dynamic libraries are built, undefined symbols should always be allowed and
the linker should not exit with an error.
llvm-svn: 217356
|
|
|
|
|
|
|
|
| |
If we are creating a PE+ executable, we need to run cvtres with
/machine:x64 instead of /machine:x86. Otherwise the resulting executable
would be invalid.
llvm-svn: 217214
|