Add PT_PHDR segment depending on its availability in linker script's
PHDRS command, fallback if no linker script is given.
Handle FILEHDR, PHDRS and FLAGS attributes of program header.
Differential Revision: http://reviews.llvm.org/D11589
llvm-svn: 244743
This has a few advantages
* Less C++ code (about 300 lines less).
* Less machine code (about 14 KB of text on a linux x86_64 build).
* It is more debugger friendly. Just set a breakpoint on the exit function and
you get the complete lld stack trace of when the error was found.
* It is a more robust API. The errors are handled early and we don't get a
std::error_code hot potato being passed around.
* In most cases the error function in a better position to print diagnostics
(it has more context).
llvm-svn: 244215
This is a direct port of the new PE/COFF linker to ELF.
It can take a single object file and generate a valid executable that executes at the first byte in the text section.
llvm-svn: 242088
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