None of the implementations replace the SimpleFile with some other file,
they just modify the SimpleFile in-place, so a direct reference to the
file is sufficient.
llvm-svn: 240167
This is an initial patch for a section-based COFF linker.
The patch has 2300 lines of code including comments and blank lines.
Before diving into details, you want to start from reading README
because it should give you an overview of the design.
All important things are written in the README file, so I write
summary here.
- The linker is already able to self-link on Windows.
- It's significantly faster than the existing implementation.
The existing one takes 5 seconds to link LLD on my machine,
while the new one only takes 1.2 seconds, even though the new
one is not multi-threaded yet. (And a proof-of-concept multi-
threaded version was able to link it in 0.5 seconds.)
- It uses much less memory (250MB vs. 2GB virtual memory space
to self-host).
- IMHO the new code is much simpler and easier to read than
the existing PE/COFF port.
http://reviews.llvm.org/D10036
llvm-svn: 238458
loadFile could load mulitple files just because yaml has a feature for
putting multiple documents in one file.
Designing a linker around what yaml can do seems like a bad idea to
me. This patch changes it to read a single file.
There are further improvements to be done to the api and they
will follow shortly.
llvm-svn: 235724
Command line options --arm-target1-rel and --arm-target1-abs have been renamed to be compatible with GNU linkers.
Two tests have been updated:
test/elf/options/target-specific-args.test
test/elf/ARM/rel-arm-target1.test
Differential Revision: http://reviews.llvm.org/D9037
llvm-svn: 235499
There's (almost) never need to keep .L symbols around for production
builds. In fact, the FreeBSD kernel explicitly specify -X beacuse the
size impact (and the subsequent performance impact) might be significant,
because we keep symbols in memory.
I was tempted to make this the default, but I haven't (yet).
PR: 23232
llvm-svn: 235357
Before we only accepted --dynamic-linker=<file> and -dynamic-linker <file>
but older versions of GNU ld (e.g. 2.17.50) accept this other form, so
try to be compatible.
PR: 23233
llvm-svn: 235282
The function took either StringRef or Twine. Since string literals are
ambiguous when resolving the overloading, many code calls used this
function with explicit type conversion. That led awkward code like
make_dynamic_error_code(Twine("Error occurred")).
This patch adds a function definition for string literals, so that
you can directly call the function with literals.
llvm-svn: 234841
This doesn't compile with MSVC 2013:
include\lld/ReaderWriter/PECOFFLinkingContext.h(356) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
include\lld/ReaderWriter/PECOFFLinkingContext.h(357) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
llvm-svn: 234676
The Native file format was designed to be the fastest on-memory or
on-disk file format for object files. The problem is that no one
is working on that. No LLVM tools can produce object files in
the Native, thus the feature of supporting the format is useless
in the linker.
This patch removes the Native file support. We can add it back
if we really want it in future.
llvm-svn: 234641
This MIPS specific option controls R_MIPS_EH relocation handling.
If -pcrel-eh-reloc is specified R_MIPS_EH relocation should be handled
like R_MIPS_PC32 relocation.
llvm-svn: 234635
These functions are "constructors" of the LinkingContexts. We already
have auxiliary classes and functions for ELFLinkingContext in the header.
They fall in the same category.
llvm-svn: 234082
Only MIPS defined the member function, but this feature is not actually
MIPS-specific. Also, the dependency to the MIPS-only member function
prevented us from merging <Arch>ELF{Object,DSO}Reader classes.
This patch moves the feature from MipsLinkingContext to LinkingContext.
llvm-svn: 234068
What we are doing in ELFTarget.h was dubious. In the file, we define
partial classes of <Arch>LinkingContexts to declare only static member
functions. We have different (complete) class definitions in other files.
They would conflict if they exist in the same compilation unit (because
the ones defined in ELFTarget.h has only static member functions).
I don't think this was valid C++.
http://reviews.llvm.org/D8797
llvm-svn: 234039
This patch provides implementation of R_ARM_TARGET1 relocation with
configuration of its behaviour from a command line. This patch provides
two command line options for GnuLd driver: --arm-target1-rel and
--arm-target1-abs (similar to ld option names with extra prefix 'arm-').
So user may choose which behaviour of R_ARM_TARGET1 is preferred for his
implementation of libc.
Differential Revision: http://reviews.llvm.org/D8707
llvm-svn: 234009
This patch defines implicit conversion between integers and PowerOf2
instances, so uses of the classes is now implicit and look like
regular integers. Now we are ready to remove the scaffolding.
llvm-svn: 233245
The new constructor's type is the same, but this one takes not a log2
value but an alignment value itself, so the meaning is totally differnet.
llvm-svn: 233244
This patch is to make instantiation and conversion to an integer explicit,
so that we can mechanically replace all occurrences of the class with
integer in the next step.
Now get() returns an alignment value rather than its log2 value.
llvm-svn: 233242
We are using log2 values and values themselves to represent alignments.
For example, alignment 8 is sometimes represented as 3 (8 == 2^3).
We want to stop using log2 values.
Because both types are regular arithmetic types, we cannot get help from
a compiler to find places we mix two representations. That makes this
merging work surprisingly hard because if I make a mistake, I'll just get
wrong results at runtime (Yay types!). In this patch, I introduced
a class to represents power-of-two values, which is basically an alias
for an integer type.
Once the migration is done, the class will be removed.
llvm-svn: 233232
This commit implements the behaviour of the SECTIONS linker script directive,
used to not only define a custom mapping between input and output sections, but
also order input sections in the output file. To do this, we modify
DefaultLayout with hooks at important places that allow us to re-order input
sections according to a custom order. We also add a hook in SegmentChunk to
allow us to calculate linker script expressions while assigning virtual
addresses to the input sections that live in a segment.
Not all SECTIONS constructs are currently supported, but only the ones that do
not use special sort orders. It adds two LIT test as practical examples of
which sections directives are currently supported.
In terms of high-level changes, it creates a new class "script::Sema" that owns
all linker script ASTs and the logic for linker script semantics as well.
ELFLinkingContext owns a single copy of Sema, which will be used throughout
the object file writing process (to layout sections as proposed by the linker
script).
Other high-level change is that the writer no longer uses a "const" copy of
the linking context. This happens because linker script expressions must be
calculated *while* calculating final virtual addresses, which is a very late
step in object file writing. While calculating these expressions, we need to
update the linker script symbol table (inside the semantics object), and, thus,
we are "modifying our context" as we prepare to write the file.
http://reviews.llvm.org/D8157
llvm-svn: 232402
Handle resolution of symbols coming from linked object files lazily.
Add implementation of handling _GLOBAL_OFFSET_TABLE_ and __exidx_start/_end symbols for ARM platform.
Differential Revision: http://reviews.llvm.org/D8159
llvm-svn: 232261
GNU LD has an option named -T/--script which allows a user to specify
a linker script to be used [1]. LLD already accepts linker scripts
without this option, but the option is widely used. Therefore it is
best to support it in LLD as well.
[1] https://sourceware.org/binutils/docs/ld/Options.html#Options
llvm-svn: 232183
I converted them to non-range-based loops in r226883 and r226893
because at that moment File::parse() may have side effects and
may update the vector that the reference returned from
LinkingContext::nodes().
Now File::parse() is free from side effects. We can use range-based
loops again.
llvm-svn: 231321
Benjamin Kramer