maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/debug-gc.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

31 lines
727 B
ArmAsm
Raw Normal View History

[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 23:55:29 +08:00
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t1 --gc-sections
# RUN: llvm-objdump -s %t1 | FileCheck %s
# CHECK: Contents of section .debug_str:
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-10-01 05:28:49 +08:00
# CHECK-NEXT: 0000 41414100 43434300 42424200 AAA.CCC.BBB.
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 22:50:26 +08:00
# CHECK: Contents of section .foo:
# CHECK-NEXT: 0000 2a000000
[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 23:55:29 +08:00
# CHECK: Contents of section .debug_info:
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-10-01 05:28:49 +08:00
# CHECK-NEXT: 0000 00000000 08000000
[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 23:55:29 +08:00
.globl _start
_start:
.section .debug_str,"MS",@progbits,1
.Linfo_string0:
.asciz "AAA"
.Linfo_string1:
.asciz "BBB"
.Linfo_string2:
[ELF] - Fixed string encoding in test. NFC. llvm-svn: 282497
2016-09-27 23:58:31 +08:00
.asciz "CCC"
Remove trailing whitespace. llvm-svn: 283372
2016-10-06 04:09:50 +08:00
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 22:50:26 +08:00
.section .foo,"M",@progbits,4
.p2align 2
.long 42
[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 23:55:29 +08:00
.section .debug_info,"",@progbits
.long .Linfo_string0
.long .Linfo_string1