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
definition below all of the header #include lines, LLD edition.
IF you want to know more details about this, you can see the recent
commits to Debug.h in LLVM. This is just the LLD segment of a cleanup
I'm doing globally for this macro.
llvm-svn: 206851
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
/ignore:<number> is a linker option to disable warning specified by
the number. We ignore the option because it does not make sense for
LLD.
llvm-svn: 206636
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
GNU LD-comptaible driver wrongly requires a space after '=' for a few
options such as "-init=<symbol>" or "-entry=<symbol>". This patch is
to fix that bug and add a few tests for it.
llvm-svn: 205693
Currently LLD accepts only "-soname <string>", but all the following
options are actually valid.
--soname=foo
--soname foo
-soname=foo
-soname foo
-h foo
This patch fixes that issue.
llvm-svn: 205662
Seems getSomething() is more common naming scheme than just a noun
to get something, so renaming these members.
Differential Revision: http://llvm-reviews.chandlerc.com/D3285
llvm-svn: 205589
Atoms with deadStripNever attribute has already been added to the
dead strip root set at end of Resolver::doDefinedAtom, so no need
to check it for each atom again.
Differential Revision: http://llvm-reviews.chandlerc.com/D3282
llvm-svn: 205575
ELFLinkingContext has a method addUndefinedAtomsFromSharedLibrary().
The method is being used to skip a shared library within --start-group
and --end-group if it's not the first iteration of the group.
We have the same, incomplete mechanism to skip a shared library within
a group too. That's implemented in ELFFileNode. It's intended to not
return a shared library on the second or further iterations in the
first place. This mechanism is preferred over
addUndefinedAtomsFromSharedLibrary because the policy is implemented
in Input Graph -- that's what Input Graph is for.
This patch removes the dupluicate feature and fixes ELFFileNode.
Differential Revision: http://llvm-reviews.chandlerc.com/D3280
llvm-svn: 205566
"x.empty()" is more idiomatic than "x.size() == 0". This patch is to
add such method and use it in LLD.
Differential Revision: http://llvm-reviews.chandlerc.com/D3279
llvm-svn: 205558
Seems clang-modernize couldn't add "override" to nested classes, so
doing it by hand. Also removed unused virtual member function that
is not overriding anything, that seems to have been added by mistake.
llvm-svn: 205552
An ordinal is set to each child of Input Graph, but no one actually
uses it. The only piece of code that gets ordinaly values is
sortInputElements in InputGraph.cpp, but it does not actually do
anything -- we assign ordinals in increasing order just before
calling sort, so when sort is called it's already sorted. It's no-op.
We can simply remove it. No functionality change.
Differential Revision: http://llvm-reviews.chandlerc.com/D3270
llvm-svn: 205501
Resolver is sending too much information to Input Graph than Input
Graph actually needs. In order to collect the detailed information,
which wouldn't be consumed by anyone, we have a good amount of code
in Resolver, Input Graph and Input Elements. This patch is to
simplify it. No functionality change.
Specifically, this patch replaces ResolverState enum with a boolean
value. The enum defines many bits to notify the progress about
linking to Input Graph using bit masks, however, what Input Graph
actually does is to compare a given value with 0. The details of
the bit mask is simply being ignored, so the efforts to collect
such data is wasted.
This patch also changes the name of the notification interface from
setResolverState to notifyProgress, to make it sounds more like
message passing style. It's not a setter but something to notify of
an update, so the new name should be more appropriate than before.
Differential Revision: http://llvm-reviews.chandlerc.com/D3267
llvm-svn: 205463
LinkingContext and InputGraph are unnecessarily entangled. Most linker
input file data, e.g. the vector containing input files, the next index
of the input file, etc. are managed by InputGraph, but only the current
input file is for no obvious reason managed by LinkingContext.
This patch is to move code from LinkingContext to InputGraph to fix it.
It's now clear who's reponsible for managing input file state, which is
InputGraph, and LinkingContext is now free from that responsibility.
It improves the readability as we now have fewer dependencies between
classes. No functionality change.
Differential Revision: http://llvm-reviews.chandlerc.com/D3259
llvm-svn: 205394
insertElementAt()'s third parameter is not only unused but also ignored
if you pass Position::END. The actual meaning of the parameter was obscure.
Differential Revision: http://llvm-reviews.chandlerc.com/D3256
llvm-svn: 205376
Group class is designed for GNU LD's --start-group and --end-group. There's
no obvious need to have two classes for it -- one as an abstract base class
and the other as a concrete class.
llvm-svn: 205375
InputGraph has too many knobs and controls that are not being used. This
patch is to remove dead code, unused features and a class. There are two
things that worth noting, besides simple dead code removal:
1. ControlNode class is removed. We had it as the base class of Group
class, but it provides no functionality particularly meaningful. We now
have shallower class hierarchy that is easier to understand.
2. InputGraph provides a feature to replace a node with its internal data.
It is being used to "expand" some type of node, such as a Linker Script
node, with its actual files. We used to have two options when replacing
it -- ExpandOnly or ExpandAndReplace. ExpandOnly was to expand it but not
remove the node from the tree. There is no use of that option in the code,
so it was a dead feature.
Differential Revision: http://llvm-reviews.chandlerc.com/D3252
llvm-svn: 205363
Asserting with cast<T> did not actually make much sense because there was no
need to use dynamic casting in the first place. We could make the compiler to
statically type check these objects.
llvm-svn: 205350
cast<X> asserts the type is correct and does not return null on failure.
So we should use cast<X> rather than dyn_cast<X> at such places where we
don't expect type conversion could fail.
llvm-svn: 205332
PECOFFFileNode::parse can be called twice -- once by WinLink driver and
once more by Driver. We want to make sure that the second call won't mess
up the internal data.
llvm-svn: 205284
Some Clang build uses .imp not .lib file extension for an import library file,
so we need to treat such file as a library file.
Ideally we should not rely on file extensions to detect file type. Instead
we should use magic bytes at beginning of a file. The GNU-compatible driver
actually does that but it made writing unit tests hard, so I chose an ad-hoc
approach for now.
llvm-svn: 205283
.gnu.linkonce sections are similar to section groups.
They were supported before section groups existed and provided a way
to resolve COMDAT sections using a different design.
There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant in a binary.
.gnu.linkonce based symbol resolution achieves that.
Review : http://llvm-reviews.chandlerc.com/D3242
llvm-svn: 205280
This reverts commit 5d5ca72a7876c3dd3dd1db83dc6a0d74be9e2cd1.
Discuss on a better design to raise error when there is a similar group with Gnu
linkonce sections and COMDAT sections.
llvm-svn: 205224
.gnu.linkonce sections are similar to section groups. They were supported before
section groups existed and provided a way to resolve COMDAT sections using a
different design. There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant. .gnu.linkonce based symbol resolution achieves that.
llvm-svn: 205163
On these tests llvm-mc will convert got relocations with a symbol to section
relocations. This is invalid, since the relocation doesn't reference the symbol
itself, so its offset in a section in irrelevant.
Given the object files, these are still valid lld tests, so just run the
tests directly on the binaries.
Found by running check-lld after fixing the relocation handling in llvm-mc.
llvm-svn: 205077
Response file is a command line argument in the form of @file. The GNU-
compatible driver expands the file contents, replacing @file argument.
Differential Revision: http://llvm-reviews.chandlerc.com/D3210
llvm-svn: 205038
This patch is to support --defsym option for ELF file format/GNU-compatible
driver. Currently it takes a symbol name followed by '=' and a number. If such
option is given, the driver sets up an absolute symbol with the specified
address. You can specify multiple --defsym options to define multiple symbols.
GNU LD's --defsym provides many more features. For example, it allows users to
specify another symbol name instead of a number to define a symbol alias, or it
even allows a symbol plus an offset (e.g. --defsym=foo+3) to define symbol-
relative alias. This patch does not support that, but will be supported in
subsequent patches.
Differential Revision: http://llvm-reviews.chandlerc.com/D3208
llvm-svn: 205029
If --allow-multiple-definition option is given, LLD does not treat duplicate
symbol error as a fatal error. GNU LD supports this option.
Differential Revision: http://llvm-reviews.chandlerc.com/D3211
llvm-svn: 205015
These classes are declared in a .cpp file but not used in the same compliation
unit. They seems to have been copy-and-pasted from ELFReader.h.
llvm-svn: 204988
Currently we use both layout-after and layout-before edges to specify atom
orders in the resulting executable. We have a complex piece of code in
LayoutPass.cpp to deal with both types of layout specifiers.
(In the following description, I denote "Atom A having a layout-after edge
to B" as "A -> B", and A's layout-before to B as "A => B".)
However, that complexity is not really needed for this reason: If there
are atoms such that A => B, B -> A is always satisifed, so using only layout-
after relationships will yield the same result as the current code.
Actually we have a piece of complex code that verifies that, for each A -> B,
B => [ X => Y => ... => Z => ] A is satsified, where X, Y, ... Z are all
zero-size atoms. We can get rid of the code from our codebase because layout-
before is basically redundant.
I think we can simplify the code for layout-after even more than this, but
I want to just remove this pass for now for simplicity.
Layout-before edges are still there for dead-stripping, so this change won't
break it. We will remove layout-before in a followup patch once we fix the
dead-stripping pass.
Differential Revision: http://llvm-reviews.chandlerc.com/D3164
llvm-svn: 204966
Use <mutex> instead of "llvm/Support/Mutex.h".
Also change the type of mutex for the context object to recursive mutex, as
the driver could acquire the lock recursively. E.g. If file A has .drectve
section containing /defaultlib:B, the driver tries to parse file B, and if
file B has .drectve section, the driver acquires the lock again.
llvm-svn: 204850
RoundTripYAML pass is removed from the regular execution pass in r204296,
so the safeguard to protect it from OOM error is no longer needed, because
we are sure that the pass is only used for tests, and test files are all
small.
We also want to see RoundTripYAML pass to fail in tests if it fails,
rather than silently skipping failing tests.
llvm-svn: 204772
If a response file is given via command line, the final command line
arguments will not appear in the log because the actual arguments are
in the given file.
This patch is to show the final command line if /verbose is specified
to help users.
llvm-svn: 204754
Response file is not NUL terminated, so when creating a StringRef for
the buffer contents, we need to pass the buffer size as well as the
pointer pointing to the buffer.
llvm-svn: 204420
If the environment variable is defined and not empty, RoundTrip tests
are run. The reason to move the tests behind the flag is because they
are too slow to enable by default.
LLD linking time on llvm-tblgen improved from 2m7s to 2.3s. About 60x
faster now in this case.
Differential Revision: http://llvm-reviews.chandlerc.com/D3126
llvm-svn: 204296
InputElement::parse() may recursively call WinLinkDriver::parse() to handle
.drectve section contents, and if /defaultlib option exists in the section,
the driver will mutate the input graph to add a new input file to the graph.
So the access to input graph needs to be protected with mutext.
llvm-svn: 204285
of GOT.
* Read addend for R_MIPS_GOT16 relocation.
* Put only high 16 bits of symbol + addend into GOT entries for
locally visible symbols.
llvm-svn: 204247
Update all of the unit tests to use the new format.
This depends on D3092.
Reviewers: ruiu
Differential Revision: http://llvm-reviews.chandlerc.com/D3093
llvm-svn: 204215
COMDAT_SELECT_LARGEST is a COMDAT type that make linker to choose the largest
definition from among all of the definition of a symbol. If the size is the
same, the choice is arbitrary.
Differential Revision: http://llvm-reviews.chandlerc.com/D3011
llvm-svn: 204172
The COFF spec says that the SectionNumber field in the symbol table is 16 bit
signed type, but MSVC treats the field as if it is unsigned.
llvm-svn: 203901
LLD fails to link symbol "_main" if the symbol is in a library file and
the library file is given as a bare argument (i.e. not with /defaultlib
option). It's because library files given as bare arguments are processed
before other libraries given with /defaultlib, so when Linker finds msvcrtd
needs a definition for "_main", the file providing the main function has
already been processed and skipped. Linker don't revisit libraries if it's
not given with /defaultlib.
To fix it this patch change the way of command line handling; files end with
".lib" are treated as if they are given with /defaultlib. I don't believe
it's 100% correct behavior but it's better than before.
llvm-svn: 203892
If the driver finds a command line option in the form of "@filename", the
option will be replaced with the content of the given file. It's an error
if a response file cannot be read.
llvm-svn: 203875
This results in some simplifications to the code where an OwningPtr had to
be used with the previous api and then ownership moved to a unique_ptr for
the rest of lld.
llvm-svn: 203809
An object whose machine type header value is unknown looks a bit odd but
is valid. If an object contains only machine-type-independent data, you
can leave the type field unspecified. Some files in oldname.lib are such
object files.
llvm-svn: 203752
Clang creates "clang-cl" as a symlink to (or a copy of) "clang" for the MSVC-
compatible driver. This patch is to do the same thing for "link" and "lld".
Differential Revision: http://llvm-reviews.chandlerc.com/D3066
llvm-svn: 203751