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

87 lines
5.1 KiB
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 -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic.macho.x86_64 | FileCheck %s
RUN: dsymutil -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic-lto.macho.x86_64 | FileCheck %s --check-prefix=CHECK-LTO
[dsymutil] Make the CachedBinaryHolder the default Replaces all uses of the old binary holder with its cached variant. Differential revision: https://reviews.llvm.org/D48770 llvm-svn: 335991
2018-06-30 00:51:52 +08:00
RUN: dsymutil -verbose -dump-debug-map -oso-prepend-path=%p %p/Inputs/basic-archive.macho.x86_64 2>&1 | FileCheck %s --check-prefix=CHECK-ARCHIVE
[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 -dump-debug-map %p/Inputs/basic.macho.x86_64 2>&1 | FileCheck %s --check-prefix=NOT-FOUND
RUN: not 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
[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-DAG: sym: _val, binAddr: 0x0000000100001004, size: 0x00000000
[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: ...
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'
[dsymutil] Make the CachedBinaryHolder the default Replaces all uses of the old binary holder with its cached variant. Differential revision: https://reviews.llvm.org/D48770 llvm-svn: 335991
2018-06-30 00:51:52 +08:00
CHECK-ARCHIVE-NEXT: loaded object.
[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-ARCHIVE-NEXT: trying to open {{.*}}/Inputs/basic1.macho.x86_64.o'
[dsymutil] Make the CachedBinaryHolder the default Replaces all uses of the old binary holder with its cached variant. Differential revision: https://reviews.llvm.org/D48770 llvm-svn: 335991
2018-06-30 00:51:52 +08:00
CHECK-ARCHIVE-NEXT: loaded object.
[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-ARCHIVE-NEXT: trying to open {{.*}}/libbasic.a(basic2.macho.x86_64.o)'
[dsymutil] Make the CachedBinaryHolder the default Replaces all uses of the old binary holder with its cached variant. Differential revision: https://reviews.llvm.org/D48770 llvm-svn: 335991
2018-06-30 00:51:52 +08:00
CHECK-ARCHIVE-NEXT: loaded archive {{.*}}/libbasic.a'
CHECK-ARCHIVE-NEXT: found member in 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
CHECK-ARCHIVE-NEXT: trying to open {{.*}}/libbasic.a(basic3.macho.x86_64.o)'
[dsymutil] Make the CachedBinaryHolder the default Replaces all uses of the old binary holder with its cached variant. Differential revision: https://reviews.llvm.org/D48770 llvm-svn: 335991
2018-06-30 00:51:52 +08:00
CHECK-ARCHIVE-NEXT: found member in 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
[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-ARCHIVE-DAG: sym: _val, binAddr: 0x0000000100001008, size: 0x00000000
[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] 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).
[dsymutil] Print architecture in warning Make the architecture part of the warning in the DebugMapParser. This makes things consistent with the Apple's internal version of dsymutil. llvm-svn: 327485
2018-03-14 17:34:54 +08:00
warning: (x86_64) /Inputs/basic1.macho.x86_64.o unable to open object file:
NOT-FOUND: warning: (x86_64) {{.*}}/Inputs/basic1.macho.x86_64.o unable to open object file: {{[Nn]o}} such file
NOT-FOUND: warning: (x86_64) {{.*}}/Inputs/basic2.macho.x86_64.o unable to open object file: {{[Nn]o}} such file
NOT-FOUND: warning: (x86_64) {{.*}}/Inputs/basic3.macho.x86_64.o unable to open object file: {{[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
[dsymutil] Upstream emitting of papertrail warnings. When running dsymutil as part of your build system, it can be desirable for warnings to be part of the end product, rather than just being emitted to the output stream. This patch upstreams that functionality. Differential revision: https://reviews.llvm.org/D44639 llvm-svn: 328965
2018-04-02 18:40:43 +08:00
Check that we correctly error out on invalid executable.
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] Unify error handling outside DwarfLinker. This is a follow-up to r327137 where we unified error handling for the DwarfLinker. This replaces calls to errs() and outs() with the appropriate ostream wrapper everywhere in dsymutil. llvm-svn: 327411
2018-03-13 23:47:38 +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: ---