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

86 lines
5.0 KiB
Plaintext
Raw Normal View History

[dsymutil] Rename -v option to -verbose The dsymutil-classic -v option dumps the tool version rather than putting it in verbose mode. Rename -v to -verbose and update the tests that use it (in the process removing it from a few tests that didn't require it anymore since the -dump-debug-map option was introduced). A followup commit will reintroduce the -v option that dumps the version. llvm-svn: 243582
2015-07-30 06:29:34 +08:00
RUN: llvm-dsymutil -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic.macho.x86_64 | FileCheck %s
RUN: llvm-dsymutil -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic-lto.macho.x86_64 | FileCheck %s --check-prefix=CHECK-LTO
RUN: llvm-dsymutil -verbose -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic-archive.macho.x86_64 | FileCheck %s --check-prefix=CHECK-ARCHIVE
RUN: llvm-dsymutil -dump-debug-map %p/Inputs/basic.macho.x86_64 2>&1 | FileCheck %s --check-prefix=NOT-FOUND
RUN: not llvm-dsymutil -dump-debug-map %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
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK: ---
[dsymutil] Make the triple detection more strict. MachOObjectFile offers a method for detecting the correct triple, use it instead of the previous approximation. This doesn't matter right now, but it will become important for mach-o universal (fat) binaries. llvm-svn: 243095
2015-07-24 14:41:04 +08:00
CHECK: triple: 'x86_64-apple-darwin'
[dsymutil] Store an optional BinaryPath in the debug map. llvm-dsymutil needs to emit dSYM companion bundles. These are binary files that replicate some of the orignal binary file properties (sections and symbols). To get acces to these properties, pass the binary path in the debug map. llvm-svn: 246011
2015-08-26 13:09:59 +08:00
CHECK: binary-path:{{.*}}/Inputs/basic.macho.x86_64
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK: filename:{{.*}}/Inputs/basic1.macho.x86_64.o
CHECK-DAG: sym: _main, objAddr: 0x0000000000000000, binAddr: 0x0000000100000EA0, size: 0x00000024
CHECK: filename{{.*}}/Inputs/basic2.macho.x86_64.o
CHECK-DAG: sym: _baz, objAddr: 0x0000000000000310, binAddr: 0x0000000100001000, size: 0x00000000
CHECK-DAG: sym: _foo, objAddr: 0x0000000000000020, binAddr: 0x0000000100000ED0, size: 0x00000050
CHECK-DAG: sym: _inc, objAddr: 0x0000000000000070, binAddr: 0x0000000100000F20, size: 0x00000017
CHECK-DAG: sym: _private_int, objAddr: 0x0000000000000560, binAddr: 0x0000000100001008, size: 0x00000000
CHECK: filename{{.*}}/Inputs/basic3.macho.x86_64.o
CHECK-DAG: sym: _bar, objAddr: 0x0000000000000020, binAddr: 0x0000000100000F40, size: 0x00000050
CHECK-DAG: sym: _inc, objAddr: 0x0000000000000070, binAddr: 0x0000000100000F90, size: 0x00000019
CHECK-DAG: sym: _val, objAddr: 0x0000000000000004, binAddr: 0x0000000100001004, size: 0x00000000
CHECK: ...
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-lto executable
CHECK-LTO-NOT: error
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK-LTO: ---
[dsymutil] Make the triple detection more strict. MachOObjectFile offers a method for detecting the correct triple, use it instead of the previous approximation. This doesn't matter right now, but it will become important for mach-o universal (fat) binaries. llvm-svn: 243095
2015-07-24 14:41:04 +08:00
CHECK-LTO: triple: 'x86_64-apple-darwin'
[dsymutil] Store an optional BinaryPath in the debug map. llvm-dsymutil needs to emit dSYM companion bundles. These are binary files that replicate some of the orignal binary file properties (sections and symbols). To get acces to these properties, pass the binary path in the debug map. llvm-svn: 246011
2015-08-26 13:09:59 +08:00
CHECK-LTO: binary-path:{{.*}}/Inputs/basic-lto.macho.x86_64
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK-LTO: /Inputs/basic-lto.macho.x86_64.o
CHECK-LTO-DAG: sym: _bar, objAddr: 0x0000000000000050, binAddr: 0x0000000100000F90, size: 0x00000024
CHECK-LTO-DAG: sym: _baz, objAddr: 0x0000000000000658, binAddr: 0x0000000100001000, size: 0x00000000
CHECK-LTO-DAG: sym: _foo, objAddr: 0x0000000000000010, binAddr: 0x0000000100000F50, size: 0x00000040
CHECK-LTO-DAG: sym: _main, objAddr: 0x0000000000000000, binAddr: 0x0000000100000F40, size: 0x00000010
CHECK-LTO-DAG: sym: _private_int, objAddr: 0x00000000000008E8, binAddr: 0x0000000100001008, size: 0x00000000
CHECK-LTO-DAG: sym: _val, objAddr: 0x00000000000008EC, binAddr: 0x0000000100001004, size: 0x00000000
CHECK-LTO: ...
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
[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.
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK-ARCHIVE: ---
[dsymutil] Make the triple detection more strict. MachOObjectFile offers a method for detecting the correct triple, use it instead of the previous approximation. This doesn't matter right now, but it will become important for mach-o universal (fat) binaries. llvm-svn: 243095
2015-07-24 14:41:04 +08:00
CHECK-ARCHIVE: triple: 'x86_64-apple-darwin'
[dsymutil] Store an optional BinaryPath in the debug map. llvm-dsymutil needs to emit dSYM companion bundles. These are binary files that replicate some of the orignal binary file properties (sections and symbols). To get acces to these properties, pass the binary path in the debug map. llvm-svn: 246011
2015-08-26 13:09:59 +08:00
CHECK-ARCHIVE: binary-path:{{.*}}/Inputs/basic-archive.macho.x86_64
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
CHECK-ARCHIVE: /Inputs/basic1.macho.x86_64.o
CHECK-ARCHIVE-DAG: sym: _main, objAddr: 0x0000000000000000, binAddr: 0x0000000100000EA0, size: 0x00000024
CHECK-ARCHIVE: /Inputs/./libbasic.a(basic2.macho.x86_64.o)
CHECK-ARCHIVE-DAG: sym: _baz, objAddr: 0x0000000000000310, binAddr: 0x0000000100001000, size: 0x00000000
CHECK-ARCHIVE-DAG: sym: _foo, objAddr: 0x0000000000000020, binAddr: 0x0000000100000ED0, size: 0x00000050
CHECK-ARCHIVE-DAG: sym: _inc, objAddr: 0x0000000000000070, binAddr: 0x0000000100000F20, size: 0x00000017
CHECK-ARCHIVE-DAG: sym: _private_int, objAddr: 0x0000000000000560, binAddr: 0x0000000100001004, size: 0x00000000
CHECK-ARCHIVE: /Inputs/./libbasic.a(basic3.macho.x86_64.o)
CHECK-ARCHIVE-DAG: sym: _bar, objAddr: 0x0000000000000020, binAddr: 0x0000000100000F40, size: 0x00000050
CHECK-ARCHIVE-DAG: sym: _inc, objAddr: 0x0000000000000070, binAddr: 0x0000000100000F90, size: 0x00000019
CHECK-ARCHIVE-DAG: sym: _val, objAddr: 0x0000000000000004, binAddr: 0x0000000100001008, size: 0x00000000
CHECK-ARCHIVE: ...
[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 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
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
NOT-FOUND: ---
[dsymutil] Make the triple detection more strict. MachOObjectFile offers a method for detecting the correct triple, use it instead of the previous approximation. This doesn't matter right now, but it will become important for mach-o universal (fat) binaries. llvm-svn: 243095
2015-07-24 14:41:04 +08:00
NOT-FOUND-NEXT: triple: 'x86_64-apple-darwin'
[dsymutil] Store an optional BinaryPath in the debug map. llvm-dsymutil needs to emit dSYM companion bundles. These are binary files that replicate some of the orignal binary file properties (sections and symbols). To get acces to these properties, pass the binary path in the debug map. llvm-svn: 246011
2015-08-26 13:09:59 +08:00
NOT-FOUND-NEXT: binary-path:{{.*}}/Inputs/basic.macho.x86_64
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
NOT-FOUND-NEXT: ...
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 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
[dsymutil] Use YAMLIO to dump debug map. Doing so will allow us to also accept a YAML debug map in input as using YAMLIO gives us the parsing for free. Being able to have textual debug maps will in turn allow much more control over the tests, because 1/ no need to check-in a binary containing the debug map and 2/ it will allow to use the same objects/IR files with made-up debug-maps to test different scenari. llvm-svn: 238781
2015-06-02 05:12:45 +08:00
NO-EXECUTABLE-NOT: ---