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/debug-map-parsing.test

78 lines
3.7 KiB
Plaintext
Raw Normal View History

Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
RUN: llvm-dsymutil -v -parse-only -oso-prepend-path=%p %p/Inputs/basic.macho.x86_64 | FileCheck %s
RUN: llvm-dsymutil -v -parse-only -oso-prepend-path=%p %p/Inputs/basic-lto.macho.x86_64 | FileCheck %s --check-prefix=CHECK-LTO
[dsymutil] Implement the BinaryHolder object and gain archive support. This object is meant to own the ObjectFiles and their underlying MemoryBuffer. It is basically the equivalent of an OwningBinary except that it efficiently handles Archives. It is optimized for efficiently providing mappings of members of the same archive when they are opened successively (which is standard in Darwin debug maps, objects from the same archive will be contiguous). Of course, the BinaryHolder will also be used by the DWARF linker once it is commited, but for now only the debug map parser uses it. With this change, you can run llvm-dsymutil on your Darwin debug build of clang and get a complete debug map for it. Differential Revision: http://reviews.llvm.org/D6690 llvm-svn: 225207
2015-01-06 05:29:28 +08:00
RUN: llvm-dsymutil -v -parse-only -oso-prepend-path=%p %p/Inputs/basic-archive.macho.x86_64 | FileCheck %s --check-prefix=CHECK-ARCHIVE
Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
RUN: llvm-dsymutil -v -parse-only %p/Inputs/basic.macho.x86_64 2>&1 | FileCheck %s --check-prefix=NOT-FOUND
RUN: not llvm-dsymutil -v -parse-only %p/Inputs/inexistant 2>&1 | FileCheck %s --check-prefix=NO-EXECUTABLE
[dsymutil] Implement the BinaryHolder object and gain archive support. This object is meant to own the ObjectFiles and their underlying MemoryBuffer. It is basically the equivalent of an OwningBinary except that it efficiently handles Archives. It is optimized for efficiently providing mappings of members of the same archive when they are opened successively (which is standard in Darwin debug maps, objects from the same archive will be contiguous). Of course, the BinaryHolder will also be used by the DWARF linker once it is commited, but for now only the debug map parser uses it. With this change, you can run llvm-dsymutil on your Darwin debug build of clang and get a complete debug map for it. Differential Revision: http://reviews.llvm.org/D6690 llvm-svn: 225207
2015-01-06 05:29:28 +08:00
Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
Check that We can parse the debug map of the basic executable.
CHECK-NOT: error
CHECK: DEBUG MAP:
CHECK: /Inputs/basic1.macho.x86_64.o:
CHECK: 0000000000000000 => 0000000100000ea0 _main
CHECK: /Inputs/basic2.macho.x86_64.o:
CHECK: 0000000000000310 => 0000000100001000 _baz
CHECK: 0000000000000020 => 0000000100000ed0 _foo
CHECK: 0000000000000070 => 0000000100000f20 _inc
CHECK: 0000000000000560 => 0000000100001008 _private_int
CHECK: /Inputs/basic3.macho.x86_64.o:
CHECK: 0000000000000020 => 0000000100000f40 _bar
CHECK: 0000000000000070 => 0000000100000f90 _inc
CHECK: 0000000000000004 => 0000000100001004 _val
CHECK: END DEBUG MAP
Check that we can parse the debug-map of the basic-lto executable
CHECK-LTO-NOT: error
CHECK-LTO: DEBUG MAP:
CHECK-LTO: /Inputs/basic-lto.macho.x86_64.o:
CHECK-LTO: 0000000000000050 => 0000000100000f90 _bar
CHECK-LTO: 0000000000000658 => 0000000100001000 _baz
CHECK-LTO: 0000000000000010 => 0000000100000f50 _foo
CHECK-LTO: 0000000000000000 => 0000000100000f40 _main
CHECK-LTO: 00000000000008e8 => 0000000100001008 _private_int
CHECK-LTO: 00000000000008ec => 0000000100001004 _val
CHECK-LTO: END DEBUG MAP
[dsymutil] Implement the BinaryHolder object and gain archive support. This object is meant to own the ObjectFiles and their underlying MemoryBuffer. It is basically the equivalent of an OwningBinary except that it efficiently handles Archives. It is optimized for efficiently providing mappings of members of the same archive when they are opened successively (which is standard in Darwin debug maps, objects from the same archive will be contiguous). Of course, the BinaryHolder will also be used by the DWARF linker once it is commited, but for now only the debug map parser uses it. With this change, you can run llvm-dsymutil on your Darwin debug build of clang and get a complete debug map for it. Differential Revision: http://reviews.llvm.org/D6690 llvm-svn: 225207
2015-01-06 05:29:28 +08:00
Check thet we correctly handle debug maps with archive members (including only
opening the archive once if mulitple of its members are used).
CHECK-ARCHIVE: trying to open {{.*}}basic-archive.macho.x86_64'
CHECK-ARCHIVE-NEXT: loaded file.
CHECK-ARCHIVE-NEXT: trying to open {{.*}}/Inputs/basic1.macho.x86_64.o'
CHECK-ARCHIVE-NEXT: loaded file.
CHECK-ARCHIVE-NEXT: trying to open {{.*}}/libbasic.a(basic2.macho.x86_64.o)'
CHECK-ARCHIVE-NEXT: opened new archive {{.*}}/libbasic.a'
CHECK-ARCHIVE-NEXT: found member in current archive.
CHECK-ARCHIVE-NEXT: trying to open {{.*}}/libbasic.a(basic3.macho.x86_64.o)'
CHECK-ARCHIVE-NEXT: found member in current archive.
CHECK-ARCHIVE: DEBUG MAP: object addr => executable addr symbol name
CHECK-ARCHIVE: /Inputs/basic1.macho.x86_64.o:
CHECK-ARCHIVE: 0000000000000000 => 0000000100000ea0 _main
CHECK-ARCHIVE: /Inputs/./libbasic.a(basic2.macho.x86_64.o):
CHECK-ARCHIVE: 0000000000000310 => 0000000100001000 _baz
CHECK-ARCHIVE: 0000000000000020 => 0000000100000ed0 _foo
CHECK-ARCHIVE: 0000000000000070 => 0000000100000f20 _inc
CHECK-ARCHIVE: 0000000000000560 => 0000000100001004 _private_int
CHECK-ARCHIVE: /Inputs/./libbasic.a(basic3.macho.x86_64.o):
CHECK-ARCHIVE: 0000000000000020 => 0000000100000f40 _bar
CHECK-ARCHIVE: 0000000000000070 => 0000000100000f90 _inc
CHECK-ARCHIVE: 0000000000000004 => 0000000100001008 _val
CHECK-ARCHIVE: END DEBUG MAP
Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
Check that we warn about missing object files (this presumes that the files aren't
present in the machine's /Inputs/ folder, which should be a pretty safe bet).
Relax debug-map-parsing.test error message check for Windows On Windows we get the string "no such file or directory". llvm-svn: 224141
2014-12-13 02:52:07 +08:00
NOT-FOUND: cannot open{{.*}}"/Inputs/basic1.macho.x86_64.o": {{[Nn]o}} such file
NOT-FOUND: cannot open{{.*}}"/Inputs/basic2.macho.x86_64.o": {{[Nn]o}} such file
NOT-FOUND: cannot open{{.*}}"/Inputs/basic3.macho.x86_64.o": {{[Nn]o}} such file
Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
NOT-FOUND: DEBUG MAP:
NOT-FOUND-NEXT: END DEBUG MAP
Check that we correctly error out on invalid executatble.
Relax debug-map-parsing.test error message check for Windows On Windows we get the string "no such file or directory". llvm-svn: 224141
2014-12-13 02:52:07 +08:00
NO-EXECUTABLE: cannot parse{{.*}}/inexistant": {{[Nn]o}} such file
Initial dsymutil tool commit. The goal of this tool is to replicate Darwin's dsymutil functionality based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does not link the debug information, it leaves it in the object files in relocatable form, but embbeds a `debug map` into the executable that describes where to find the debug information and how to relocate it. When releasing/archiving a binary, dsymutil is called to link all the DWARF information into a `dsym bundle` that can distributed/stored along with the binary. With this commit, the LLVM based dsymutil is just able to parse the STABS debug maps embedded by ld64 in linked binaries (and not all of them, for example archives aren't supported yet). Note that the tool directory is called dsymutil, but the executable is currently called llvm-dsymutil. This discrepancy will disappear once the tool will be feature complete. At this point the executable will be renamed to dsymutil, but until then you do not want it to override the system one. Differential Revision: http://reviews.llvm.org/D6242 llvm-svn: 224134
2014-12-13 01:31:24 +08:00
NO-EXECUTABLE-NOT: DEBUG MAP