maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/dsymutil/X86/common-sym.test

25 lines
785 B
Plaintext
Raw Normal View History

[dsymutil] Rename llvm-dsymutil -> dsymutil Now that almost all functionality of Apple's dsymutil has been upstreamed, the open source variant can be used as a drop in replacement. Hence we feel it's no longer necessary to have the llvm prefix. Differential revision: https://reviews.llvm.org/D44527 llvm-svn: 327790
2018-03-18 19:38:41 +08:00
RUN: dsymutil -oso-prepend-path %p/.. %p/../Inputs/common.macho.x86_64 -f -o - | llvm-dwarfdump -v -debug-info - | FileCheck %s
[dsymutil] Fix handling of common symbols. llvm-dsymutil was misinterpreting the value of common symbols as their address when it actually contains their size. This didn't impact llvm-dsymutil's ability to link the debug information for common symbols because these are always found by name and not by address. Things could however go wrong when the size of a common object matched the object file address of another symbol. Depending on the link order of the symbols the common object might incorrectly evict this other object from the address to symbol mapping, and then link the evicted symbol with a wrong binary address. Use the new ability to have symbols without an object file address to fix this. llvm-svn: 259318
2016-01-31 12:29:34 +08:00
The test was compiled from a single source:
$ cat common.c
char common[16];
int main() { return 0;}
void bar() {}
$ clang -g -c common.c -o common.macho.x86_64.o
$ clang common.macho.x86_64.o -o common.macho.x86_64
CHECK: DW_TAG_variable
CHECK: DW_AT_name {{.*}} "common"
CHECK-NOT: {{NULL|DW_TAG}}
[dwarfdump] Pretty print location expressions and location lists Summary: Based on Fred's patch here: https://reviews.llvm.org/D6771 I can't seem to commandeer the old review, so I'm creating a new one. With that change the locations exrpessions are pretty printed inline in the DIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0) And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4) Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0) The debug_loc(.dwo) dumping in changed accordingly to factor the code. Reviewers: dblaikie, aprantl, friss Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D37123 llvm-svn: 312042
2017-08-30 05:41:21 +08:00
CHECK: DW_AT_location {{.*}} (DW_OP_addr 0x100001000)
[dsymutil] Fix handling of common symbols. llvm-dsymutil was misinterpreting the value of common symbols as their address when it actually contains their size. This didn't impact llvm-dsymutil's ability to link the debug information for common symbols because these are always found by name and not by address. Things could however go wrong when the size of a common object matched the object file address of another symbol. Depending on the link order of the symbols the common object might incorrectly evict this other object from the address to symbol mapping, and then link the evicted symbol with a wrong binary address. Use the new ability to have symbols without an object file address to fix this. llvm-svn: 259318
2016-01-31 12:29:34 +08:00
CHECK: DW_TAG_subprogram
CHECK-NEXT: DW_AT_low_pc{{.*}}(0x0000000100000f80)
CHECK-NOT: {{NULL|DW_TAG}}
CHECK: DW_AT_name {{.*}} "main"
CHECK: DW_TAG_subprogram
CHECK-NEXT: DW_AT_low_pc{{.*}}(0x0000000100000f90)
CHECK-NOT: {{NULL|DW_TAG}}
CHECK: DW_AT_name {{.*}} "bar"