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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

44 lines
781 B
CMake
Raw Normal View History

[dsymutil] Tablegenify option parsing This patch reimplements command line option parsing in dsymutil with Tablegen and libOption. The main motivation for this change is to prevent clashes with other cl::opt options defined in llvm. Although it's a bit more heavyweight, it has some nice advantages such as no global static initializers and better separation between the code and the option definitions. I also used this opportunity to improve how dsymutil deals with incompatible options. Instead of having checks spread across the code, everything is now grouped together in verifyOptions. The fact that the options are no longer global means that we need to pass them around a bit more, but I think it's worth the trade-off. Differential revision: https://reviews.llvm.org/D68361 llvm-svn: 373622
2019-10-04 00:34:41 +08:00
set(LLVM_TARGET_DEFINITIONS Options.td)
tablegen(LLVM Options.inc -gen-opt-parser-defs)
add_public_tablegen_target(DsymutilTableGen)
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
Break false dependencies on target libraries Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
2019-05-24 07:02:56 +08:00
AllTargetsCodeGens
AllTargetsDescs
AllTargetsInfos
[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
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][Debuginfo][NFC] Reland: Refactor dsymutil to separate DWARF optimizing part. #2. Summary: This patch relands D71271. The problem with D71271 is that it has cyclic dependency: CodeGen->AsmPrinter->DebugInfoDWARF->CodeGen. To avoid cyclic dependency this patch puts implementation for DWARFOptimizer into separate library: lib/DWARFLinker. Thus the difference between this patch and D71271 is in that DWARFOptimizer renamed into DWARFLinker and it`s files are put into lib/DWARFLinker. Reviewers: JDevlieghere, friss, dblaikie, aprantl Reviewed By: JDevlieghere Subscribers: thegameg, merge_guards_bot, probinson, mgorny, hiraditya, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D71839
2019-12-21 00:23:31 +08:00
DWARFLinker
[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
Fix building shared libraries broken by 8e48e8e3e32.
2019-12-06 21:04:16 +08:00
CodeGen
[dsymutil] Tablegenify option parsing This patch reimplements command line option parsing in dsymutil with Tablegen and libOption. The main motivation for this change is to prevent clashes with other cl::opt options defined in llvm. Although it's a bit more heavyweight, it has some nice advantages such as no global static initializers and better separation between the code and the option definitions. I also used this opportunity to improve how dsymutil deals with incompatible options. Instead of having checks spread across the code, everything is now grouped together in verifyOptions. The fact that the options are no longer global means that we need to pass them around a bit more, but I think it's worth the trade-off. Differential revision: https://reviews.llvm.org/D68361 llvm-svn: 373622
2019-10-04 00:34:41 +08:00
Option
[dsymutil] Add support for linking remarks This adds support to dsymutil for linking remark files and placing them in the final .dSYM bundle. The result will be placed in: * a.out.dSYM/Contents/Resources/Remarks/a.out or * a.out.dSYM/Contents/Resources/Remarks/a.out-<arch> for universal binaries When multi-threaded, this runs a third thread which loops over all the object files and parses remarks as it finds __remarks sections. Testing this involves running dsymutil on pre-built binaries and object files, then running llvm-bcanalyzer on the final result to check for remarks. Differential Revision: https://reviews.llvm.org/D69142
2019-10-01 00:05:12 +08:00
Remarks
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
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
)
[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
add_llvm_tool(dsymutil
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.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
[dsymutil] Upstream getBundleInfo implementation This patch implements `getBundleInfo`, which uses CoreFoundation to obtain information about the CFBundle. This information is needed to populate the Plist in the dSYM bundle. This change only applies to darwin and is an NFC as far as other platforms are concerned. Differential revision: https://reviews.llvm.org/D40244 llvm-svn: 319416
2017-11-30 18:25:28 +08:00
CFBundle.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
[Dsymutil][Debuginfo][NFC] Reland: Refactor dsymutil to separate DWARF optimizing part. #2. Summary: This patch relands D71271. The problem with D71271 is that it has cyclic dependency: CodeGen->AsmPrinter->DebugInfoDWARF->CodeGen. To avoid cyclic dependency this patch puts implementation for DWARFOptimizer into separate library: lib/DWARFLinker. Thus the difference between this patch and D71271 is in that DWARFOptimizer renamed into DWARFLinker and it`s files are put into lib/DWARFLinker. Reviewers: JDevlieghere, friss, dblaikie, aprantl Reviewed By: JDevlieghere Subscribers: thegameg, merge_guards_bot, probinson, mgorny, hiraditya, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D71839
2019-12-21 00:23:31 +08:00
DwarfLinkerForBinary.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
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
[dsymutil] Add reproducers to dsymutil Add support for generating a dsymutil reproducer. The result is a folder containing all the object files for linking. When --gen-reproducer is passed, dsymutil uses a FileCollectorFileSystem which keeps track of all the files used by dsymutil. These files are copied into a temporary directory when dsymutil exists. When this path is passed to --use-reproducer, dsymutil uses a RedirectingFileSystem that will use the files from the reproducer directory instead of the actual paths. This means you don't need to mess with the OSO path prefix. Differential revision: https://reviews.llvm.org/D79398
2020-05-22 01:57:53 +08:00
Reproducer.cpp
[dsymutil] Upstream unobfuscation logic. The unobufscation support for BCSymbolMaps was the last piece of code that hasn't been upstreamed yet. This patch contains a reworked version of the existing code and relevant tests. Differential revision: https://reviews.llvm.org/D56346 llvm-svn: 350580
2019-01-08 07:27:25 +08:00
SymbolMap.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
[dsymutil] Tablegenify option parsing This patch reimplements command line option parsing in dsymutil with Tablegen and libOption. The main motivation for this change is to prevent clashes with other cl::opt options defined in llvm. Although it's a bit more heavyweight, it has some nice advantages such as no global static initializers and better separation between the code and the option definitions. I also used this opportunity to improve how dsymutil deals with incompatible options. Instead of having checks spread across the code, everything is now grouped together in verifyOptions. The fact that the options are no longer global means that we need to pass them around a bit more, but I think it's worth the trade-off. Differential revision: https://reviews.llvm.org/D68361 llvm-svn: 373622
2019-10-04 00:34:41 +08:00
${tablegen_deps}
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
)
build: add the ability to create a symlink for dsymutil Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror `LLVM_INSTALL_BINUTILS_SYMLINKS`. For now, this allows us to create symlinks for `dsymutil` to `llvm-dsymutil`. This option is off by default, but the user can enable it. llvm-svn: 326381
2018-03-01 07:00:50 +08:00
if(APPLE)
[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
target_link_libraries(dsymutil PRIVATE "-framework CoreFoundation")
build: add the ability to create a symlink for dsymutil Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror `LLVM_INSTALL_BINUTILS_SYMLINKS`. For now, this allows us to create symlinks for `dsymutil` to `llvm-dsymutil`. This option is off by default, but the user can enable it. llvm-svn: 326381
2018-03-01 07:00:50 +08:00
endif(APPLE)
[dsymutil] Explicitly link against libatomic when necessary In some systems, such as RISC-V, atomic support requires explicit linking against '-latomic' (see https://github.com/riscv/riscv-gcc/issues/12). Reviewers: davezarzycki, hhb, beanz, jfb, JDevlieghere Reviewed By: beanz, JDevlieghere Tags: #llvm Differential Revision: https://reviews.llvm.org/D69003
2020-02-18 06:26:59 +08:00
if(HAVE_CXX_ATOMICS_WITH_LIB OR HAVE_CXX_ATOMICS64_WITH_LIB)
target_link_libraries(dsymutil PRIVATE atomic)
endif()