The format is not exactly the same as the one in bfd since bfd always
follows a linker script and prints it along.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291958 91177308-0d34-0410-b5e6-96231b3b80d8
The effect is that the nobits section gets space allocated on disk.
Both bfd and gold allow this with linker scripts. To try to keep
things simple in lld, always allow it for now.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291795 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
That variable was of type DenseMap<StringRef, unsigned>, but the
unsigned numbers needed to be monotonicly increasing numbers because
the implementation that used the variable depended on that fact.
That was an implementation detail and shouldn't have leaked into Config.
This patch simplifies its type to std::vector<StringRef>.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290151 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
The .ARM.exidx table has an entry for each function with the first entry
giving the start address of the function, the table is sorted in ascending
order of function address. Given a PC value, the unwinder will search the
table for the entry that contains the PC value.
If the table entry happens to be the last, the range of the addresses that
the final unwinding table describes will extend to the end of the address
space. To prevent an incorrect address outside the address range of the
program matching the last entry we follow ld.bfd's example and add a
sentinel EXIDX_CANTUNWIND entry at the end of the table. This gives the
final real table entry an upper bound.
In addition the llvm libunwind unwinder currently depends on the presence
of a sentinel entry (PR31091).
Differential revision: https://reviews.llvm.org/D26977
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287869 91177308-0d34-0410-b5e6-96231b3b80d8
Filler expressions in linker script "=fillexp" are always handled
as 32-bit integers. Thus the new type is more natural.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287445 91177308-0d34-0410-b5e6-96231b3b80d8
Eugene Leviant
Rafael Espindola
Rui Ueyama
Peter Smith