llvm-mirror/tools/dsymutil/CMakeLists.txt

set(LLVM_LINK_COMPONENTS
  ${LLVM_TARGETS_TO_BUILD}
  AsmPrinter
  DebugInfoDWARF
  MC
  Object
  Support
  Target
  )

add_llvm_tool(llvm-dsymutil
  dsymutil.cpp
  BinaryHolder.cpp
  DebugMap.cpp
  DwarfLinker.cpp
  MachODebugMapParser.cpp
  MachOUtils.cpp

  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-12 18:31:24 +01: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 01:29:11 +01: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-30 19:07:45 +01: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 01:29:11 +01: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-12 18:31:24 +01: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-03 21:07:51 +02: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-12 18:31:24 +01: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-05 22:29:28 +01: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-12 18:31:24 +01: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-05 20:27:44 +02: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 03:02:46 +01: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-12 18:31:24 +01:00			`)`