As specified here:
* https://sourceware.org/binutils/docs/ld/MEMORY.html#MEMORY
There are two deviations from what is specified for GNU ld:
1. Only integer constants and *not* constant expressions
are allowed in `LENGTH` and `ORIGIN` initializations.
2. The `I` and `L` attributes are *not* implemented.
With (1) there is currently no easy way to evaluate integer
only constant expressions. This can be enhanced in the
future.
With (2) it isn't clear how these flags map to the `SHF_*`
flags or if they even make sense for an ELF linker.
Differential Revision: https://reviews.llvm.org/D28911
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@292875 91177308-0d34-0410-b5e6-96231b3b80d8
This actually simplifies the code a bit as now all local symbols are
handled uniformly.
This should fix the build of www/webkit2-gtk3.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291569 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows for linker scripts to assign a new value
to a symbol that is already defined (either in an object file
or the linker script itself).
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291459 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291413 91177308-0d34-0410-b5e6-96231b3b80d8
After Mark's patch I was wondering what was the rationale for the ELF
spec requiring us to merge only sections with matching flags and
types. I tried emailing
https://groups.google.com/forum/#!forum/generic-abi, but looks like my
emails are not being posted (the list is probably moderated). I
emailed Cary Coutant instead.
Cary pointed out that the section was a late addition and didn't got
the scrutiny it deserved. Given that and the problems found by
implementing the letter of the standard, I propose changing lld to
merge all sections with the same name and issue errors if the types or
some critical flags are different.
This should allow an unmodified firefox linked with lld to run.
This also merges some code with the linkerscript path.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291107 91177308-0d34-0410-b5e6-96231b3b80d8
We managed new MemoryBuffers in different ways in LinkerScript.cpp and
Driver.cpp. With this patch, they are managed in the same way.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290411 91177308-0d34-0410-b5e6-96231b3b80d8
DefinedSynthetic is not created for a real ELF object, so it doesn't
have to be a template function. It has a virtual st_value, which is
either 32 bit or 64 bit, but we can simply use 64 bit.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290241 91177308-0d34-0410-b5e6-96231b3b80d8
It was revealed by D27831.
If we have linkerscript that includes another one that sets OUTPUT for example:
RUN: echo "INCLUDE \"foo.script\"" > %t.script
RUN: echo "OUTPUT(\"%t.out\")" > %T/foo.script
then we do:
void ScriptParser::readInclude() {
...
std::unique_ptr<MemoryBuffer> &MB = *MBOrErr;
tokenize(MB->getMemBufferRef());
OwningMBs.push_back(std::move(MB));
}
void ScriptParser::readOutput() {
...
Config->OutputFile = unquote(Tok);
...
}
Problem is that OwningMBs are destroyed after script parser do its job.
So all Toks are dead and Config->OutputFile points to destroyed data.
Patch suggests to save all included scripts into using string Saver.
Differential revision: https://reviews.llvm.org/D27987
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290238 91177308-0d34-0410-b5e6-96231b3b80d8
This handles all the corner cases if setting a section address:
- If the address is too low, we cannot allocate the program headers.
- If the load address is lowered, we have to do that before finalize
This also shares some code with the linker script since it was already
hitting similar cases.
This is used by the freebsd boot loader. It is not clear if we need to
support this with a non binary output, but it is not as bad as I was
expecting.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290136 91177308-0d34-0410-b5e6-96231b3b80d8
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290062 91177308-0d34-0410-b5e6-96231b3b80d8
PR31335 shows that we do that in next case:
SECTIONS { .text 0x2000 : {. = 0x100 ; *(.text) } }
though documentations says that "If . is used inside a section
description however, it refers to the byte offset from the start
of that section, not an absolute address. " looks does not work
as documented in bfd (as mentioned in comments for PR31335).
Until we find out the expected behavior was suggested at least not
to 'crash', what we do after trying to generate huge file.
Differential revision: https://reviews.llvm.org/D27712
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289782 91177308-0d34-0410-b5e6-96231b3b80d8
Eugene Leviant
Rui Ueyama
Meador Inge
George Rimar
Rafael Espindola