maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/tools/dsymutil/CMakeLists.txt

23 lines
291 B
CMake
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
set(LLVM_LINK_COMPONENTS
[dsymutil] Add the DwarfStreamer class. This class is responsible for getting the linked data to the disk in the appropriate form. Today it it an empty shell that just instantiates an MC layer. As we do not put anything in the resulting file yet, we just check it has the right architecture (and check that -o does the right thing). To be able to create all the components, this commit adds a few dependencies to llvm-dsymutil, namely all-targets, MC and AsmPrinter. Also add a -no-output option, so that tests that do not need the binary result can continue to run even if they do not have the required target linked in. llvm-svn: 230824
2015-02-28 08:29:11 +08:00
${LLVM_TARGETS_TO_BUILD}
AsmPrinter
Move DebugInfo to DebugInfo/DWARF. In preparation for adding PDB support to LLVM, this moves the DWARF parsing code to its own subdirectory under DebugInfo, and renames LLVMDebugInfo to LLVMDebugInfoDWARF. This is purely a mechanical / build system change. Differential Revision: http://reviews.llvm.org/D7269 Reviewed by: Eric Christopher llvm-svn: 227586
2015-01-31 02:07:45 +08:00
DebugInfoDWARF
[dsymutil] Add the DwarfStreamer class. This class is responsible for getting the linked data to the disk in the appropriate form. Today it it an empty shell that just instantiates an MC layer. As we do not put anything in the resulting file yet, we just check it has the right architecture (and check that -o does the right thing). To be able to create all the components, this commit adds a few dependencies to llvm-dsymutil, namely all-targets, MC and AsmPrinter. Also add a -no-output option, so that tests that do not need the binary result can continue to run even if they do not have the required target linked in. llvm-svn: 230824
2015-02-28 08:29:11 +08:00
MC
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
Object
Support
add missing dependency on Target lib for tools This was exposed by r238842 (which was reverted by r238900) when doing a CMake build with -DBUILD_SHARED_LIBS=ON. llvm-svn: 238953
2015-06-04 03:07:51 +08:00
Target
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
)
add_llvm_tool(llvm-dsymutil
dsymutil.cpp
[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
BinaryHolder.cpp
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
DebugMap.cpp
DwarfLinker.cpp
MachODebugMapParser.cpp
[dsymutil] Implement support for handling mach-o universal binaries as main input/output. The DWARF linker isn't touched by this, the implementation links individual files and merges them together into a fat binary by calling out to the 'lipo' utility. The main change is that the MachODebugMapParser can now return multiple debug maps for a single binary. The test just verifies that lipo would be invoked correctly, but doesn't actually generate a binary. This mimics the way clang tests its external iplatform tools integration. llvm-svn: 244087
2015-08-06 02:27:44 +08:00
MachOUtils.cpp
[CMake] llvm-dsymutil depends on intrinsics_gen DwarfLinker.cpp has the following include chain: llvm/CodeGen/AsmPrinter.h llvm/CodeGen/MachineFunctionPass.h llvm/CodeGen/MachineFunction.h llvm/CodeGen/MachineBasicBlock.h llvm/CodeGen/MachineInstr.h llvm/Analysis/AliasAnalysis.h llvm/IR/CallSite.h llvm/IR/Attributes.h llvm/IR/Attributes.gen This means llvm-dsymutil needs to depend on intrinsics_gen. llvm-svn: 287419
2016-11-19 10:02:46 +08:00
DEPENDS
intrinsics_gen
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
)