summaryrefslogtreecommitdiffstats
path: root/llvm/test/tools/dsymutil/Inputs
Commit message (Collapse)AuthorAgeFilesLines
...
* dsymutil: Only warn about missing clang modules once.Adrian Prantl2016-01-131-0/+0
| | | | | | rdar://problem/22269336 llvm-svn: 257664
* [dsymutil] Ignore absolute symbols in the debug mapFrederic Riss2015-12-112-0/+0
| | | | | | | | | | | | Quoting from the comment added to the code: // Objective-C on i386 uses artificial absolute symbols to // perform some link time checks. Those symbols have a fixed 0 // address that might conflict with real symbols in the object // file. As I cannot see a way for absolute symbols to find // their way into the debug information, let's just ignore those. llvm-svn: 255350
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-052-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
* dsymutil: Don't prune forward declarations inside of an imported TAG_moduleAdrian Prantl2015-10-052-0/+0
| | | | | | | | if there exists not definition for the type. For this to work, we need to clone the imported modules before building the decl context chains of the DIEs in the non-skeleton CUs. llvm-svn: 249362
* dsymutil: Also ignore the ByteSize when building the DeclContext cache forAdrian Prantl2015-10-023-0/+0
| | | | | | | | clang modules. Forward decls of ObjC interfaces don't have a bytesize. llvm-svn: 249110
* dsymutil: Fix the condition to distinguish module imports form definitions.Adrian Prantl2015-09-242-0/+0
| | | | llvm-svn: 248512
* dsymutil: Don't prune forward declarations inside a module definition.Adrian Prantl2015-09-233-0/+0
| | | | llvm-svn: 248428
* Fix this dsymutil testcase by not passing in a path to the modulemap file,Adrian Prantl2015-09-231-0/+0
| | | | | | | | so the lookup works as expected after prepending the oso-prepend-path. This manifested only on Windows, because "/" is not a relative path there. llvm-svn: 248423
* dsymutil: print a warning when there is a module hash mismatch.Adrian Prantl2015-09-235-0/+0
| | | | | | | This also updates the module binaries in the test directory because their module hash mismatched. llvm-svn: 248396
* dsymutil: Follow references to clang modules and recursively clone theAdrian Prantl2015-09-223-0/+0
| | | | | | | | debug info. This does not yet resolve external type references. llvm-svn: 248331
* [dsymutil] Discard useless location attributes.Frederic Riss2015-09-111-0/+0
| | | | | | | | | | | | | | When cloning the debug info for a function that hasn't been linked, strip the DIEs from all location attributes that wouldn't contain any meaningful information anyway. This kind of situation can happen when a function got discarded by the linker, but its debug information is still wanted in the final link because it was marked as required as some other DIE dependency. The easiest way to get into that situation is to have using directives. They get linked unconditionally, but their targets might not always be present. llvm-svn: 247386
* Reapply r246012 [dsymutil] Emit real dSYM companion binaries.Frederic Riss2015-09-021-0/+0
| | | | | | | | | | | | | | | | | | | | | | | With a fix for big endian machines. Thanks to Daniel Sanders for the debugging! Original commit message: The binaries containing the linked DWARF generated by dsymutil are not standard relocatable object files like emitted did previsously. They should be dSYM companion files, which means they have a different file type in the header, but also a couple other peculiarities: - they contain the segments and sections from the original binary in their load commands, but not the actual contents. This means they get an address and a size, but their offset is always 0 (but these are not virtual sections) - they also conatin all the defined symbols from the original binary This makes MC a really bad fit to emit these kind of binaries. The approach that was used in this patch is to leverage MC's section layout for the debug sections, but to use a replacement for MachObjectWriter that lives in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter were reused too. llvm-svn: 246673
* [dsymutil] Fix testcase.Frederic Riss2015-08-311-0/+0
| | | | | | | | This testcase required 2 copies of the same file, and the second copy was missing. It was currently working because of a bug I'm about to fix. llvm-svn: 246411
* [dsymutil] Do not crash on empty debug_range range.Frederic Riss2015-08-311-0/+0
| | | | | | | | | | The fix is trivial (The actual patch is 2 lines, but as it changes indentation it looks like more). clang does not produce this kind of (slightly bogus) debug info anymore, thus I had to rely on a hand-crafted assembly test to trigger that case. llvm-svn: 246410
* [dsymutil] Fix handling of inlined_subprogram low_pcsFrederic Riss2015-08-311-0/+0
| | | | | | | | | The value of an inlined subprogram low_pc attribute should not get relocated, but it can happen that it matches the enclosing function's start address and thus gets the generic treatment. Special case it to avoid applying the PC offset twice. llvm-svn: 246406
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-282-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* Revert "[dsymutil] Emit real dSYM companion binaries."Frederic Riss2015-08-261-0/+0
| | | | | | | This reverts commit r246012. Some bots do not like it (mips/s390). llvm-svn: 246019
* [dsymutil] Emit real dSYM companion binaries.Frederic Riss2015-08-261-0/+0
| | | | | | | | | | | | | | | | | | | The binaries containing the linked DWARF generated by dsymutil are not standard relocatable object files like emitted did previsously. They should be dSYM companion files, which means they have a different file type in the header, but also a couple other peculiarities: - they contain the segments and sections from the original binary in their load commands, but not the actual contents. This means they get an address and a size, but their offset is always 0 (but these are not virtual sections) - they also conatin all the defined symbols from the original binary This makes MC a really bad fit to emit these kind of binaries. The approach that was used in this patch is to leverage MC's section layout for the debug sections, but to use a replacement for MachObjectWriter that lives in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter were reused too. llvm-svn: 246012
* [dsymutil] Remove old ODR uniquing testsFrederic Riss2015-08-2315-767/+0
| | | | | | | These tests have been obsoleted by the refactored versions introduced in the previous commit. llvm-svn: 245804
* [dsymutil] Refactor ODR uniquing tests to be more readable.Frederic Riss2015-08-236-0/+0
| | | | | | | | | This patch adds all the refactored tests in new files, the old tests will be removed by a followup commit. Thanks to D. Blaikie for all the feedback. llvm-svn: 245803
* [dsymutil] Use the new MCDwarfLineTableParams customization to emit linetablesFrederic Riss2015-08-072-0/+6
| | | | | | | | llvm-dsymutil has to be able to process debug info produced by other compilers which use different line table settings. The testcase wasn't generated by another compiler, but by a modified clang. llvm-svn: 244319
* [dsymutil] Update source used to generate test binary.Frederic Riss2015-08-051-2/+13
| | | | | | Forgot to include that in the last commit. llvm-svn: 244171
* [dsymutil] Add support for the -arch option.Frederic Riss2015-08-052-0/+0
| | | | | | | | This option allows to select a subset of the architectures when performing a universal binary link. The filter is done completely in the mach-o specific part of the code. llvm-svn: 244160
* [dsymutil] Implement support for handling mach-o universal binaries as main ↵Frederic Riss2015-08-051-0/+0
| | | | | | | | | | | | | | | | | 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
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-032-2/+2
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-319-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags, using `DW_TAG_variable` in their place Stop exposing the `tag:` field at all in the assembly format for `DILocalVariable`. Most of the testcase updates were generated by the following sed script: find test/ -name "*.ll" -o -name "*.mir" | xargs grep -l 'DILocalVariable' | xargs sed -i '' \ -e 's/tag: DW_TAG_arg_variable, //' \ -e 's/tag: DW_TAG_auto_variable, //' There were only a handful of tests in `test/Assembly` that I needed to update by hand. (Note: a follow-up could change `DILocalVariable::DILocalVariable()` to set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable` (as appropriate), instead of having that logic magically in the backend in `DbgVariable`. I've added a FIXME to that effect.) llvm-svn: 243774
* [dsymutil] Implement support for universal mach-o object files.Frederic Riss2015-07-243-0/+17
| | | | | | | | | | | | | This patch allows llvm-dsymutil to read universal (aka fat) macho object files and archives. The patch touches nearly everything in the BinaryHolder, but it is fairly mechinical: the methods that returned MemoryBufferRefs or ObjectFiles now return a vector of those, and the high-level access function takes a triple argument to select the architecture. There is no support yet for handling fat executables and thus no support for writing fat object files. llvm-svn: 243096
* [dsymutil] Implement ODR uniquing for C++ code.Frederic Riss2015-07-2115-0/+767
| | | | | | | | | | | | | | | | | This optimization allows the DWARF linker to reuse definition of types it has emitted in previous CUs rather than reemitting them in each CU that references them. The size and link time gains are huge. For example when linking the DWARF for a debug build of clang, this generates a ~150M dwarf file instead of a ~700M one (the numbers date back a bit and must not be totally accurate these days). As with all the other parts of the llvm-dsymutil codebase, the goal is to keep bit-for-bit compatibility with dsymutil-classic. The code is littered with a lot of FIXMEs that should be addressed once we can get rid of the compatibilty goal. llvm-svn: 242847
* [dsymutil] Add support for linking the debug_frame section.Frederic Riss2015-06-053-0/+152
| | | | | | | | | | | Linking the debug frame section is actually very easy as we just have to patch the start address in the FDE header and then copy the rest of the FDE without even looking at it. The only small complexity comes from the handling of the CIEs that we should unique across object file. This is also really easy by using a StringMap keyed on the raw contents of the CIE. llvm-svn: 239198
* [dsymutil] Fix location cloning for newer dwarf versions.Frederic Riss2015-03-132-0/+0
| | | | | | | | The typo got unnoticed because we were testing only on Dwarf 2. Add a Dwarf4 test that exercises the code path, and also tests some newer FORMs that the other test doesn't cover. llvm-svn: 232191
* [dsymutil] Implement the BinaryHolder object and gain archive support.Frederic Riss2015-01-053-0/+3
| | | | | | | | | | | | | | | | | | | 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
* Initial dsymutil tool commit.Frederic Riss2014-12-129-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Initial dsymutil tool commit."Frederic Riss2014-12-099-67/+0
| | | | | | This reverts commit r223793. The review thread wasn't concluded. llvm-svn: 223794
* Initial dsymutil tool commit.Frederic Riss2014-12-099-0/+67
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: 223793
OpenPOWER on IntegriCloud