Commit Graph

6 Commits

Author SHA1 Message Date
Rui Ueyama 46557f94d0 Fix 32-bit buildbots.
The result of hash_value(StringRef) depends on sizeof(size_t).
That causes lld to create different mergeable table contents on
32-bit machines.

This patch is to use xxHash64 so that we get the same hash values
on 32-bit machines.

llvm-svn: 314603
2017-09-30 21:28:49 +00:00
Rafael Espindola 2adccee13f Don't gc non-alloca non-string pieces.
We were already doing it for strings. This matches the behavior of
bfd and gold.

llvm-svn: 284598
2016-10-19 14:50:26 +00:00
Rui Ueyama b66260ac17 Remove trailing whitespace.
llvm-svn: 283372
2016-10-05 20:09:50 +00:00
Eugene Leviant d2778848ef Don't GC non-alloc mergeable section pieces
Differential revision: https://reviews.llvm.org/D25033

llvm-svn: 282708
2016-09-29 10:27:10 +00:00
George Rimar 3150799859 [ELF] - Fixed string encoding in test. NFC.
llvm-svn: 282497
2016-09-27 15:58:31 +00:00
George Rimar 74661eb040 [ELF] - Fixed linkage error when using -g --gc-sections together.
r282444 introduced new issue, sample program below
fails to link on

assert(Piece.Live);
int main() { return 0; }
clang test.cpp -c -o out.o -g
ld.lld -flavor gnu --gc-sections out.o -o out

Problem is that .debug_info contains relocations to .debug_str:
Section (7) .rela.debug_info {
..

0xC R_X86_64_32 .debug_str 0x0
0x12 R_X86_64_32 .debug_str 0x37
..
But we do not preserve .debug_str in a right way now.

To fix this we should ignore relocations from non-allocatable sections to allocatable
to allow GC work at full power, but still should proccess relocations from non-allocatable to non-allocatable sections
as usual to mark some parts of debug sections alive to keep them so we do not end 
up with such assert when trying to access dead pieces. That looks like what gold/ld do, they do 
not strip .debug_str section from what I saw using sample provided.

Thanks to Evgeny Leviant for suggestions about how to fix this.

Differential revision: https://reviews.llvm.org/D24967

llvm-svn: 282495
2016-09-27 15:55:29 +00:00