[PATCH] D37771: llvm-dwarfdump: automatically dump both regular and .dwo variant of sections

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 13 14:12:18 PDT 2017


Nothing other than the file name. It's just another object file otherwise
(I mean it doesn't have .text, etc)

On Wed, Sep 13, 2017 at 2:11 PM Adrian Prantl <aprantl at apple.com> wrote:

> On Sep 13, 2017, at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Wed, Sep 13, 2017 at 2:06 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>> On Sep 13, 2017, at 2:01 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Wed, Sep 13, 2017 at 1:58 PM Adrian Prantl via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> aprantl updated this revision to Diff 115111.
>>> aprantl added a comment.
>>> Herald added a subscriber: javed.absar.
>>>
>>> With this update:
>>>
>>> 1. llvm-dwarfdump --all prints only section headers (like `.debug_info
>>> contents:`) of non-empty sections.
>>>
>>> 2a. llvm-dwarfdump --<debug-info, ...> always prints a section header
>>> 2b. On platforms that support DWOs, llvm-dwarfdump --<debug-info ..>
>>> also always prints a section header for the corresponding .dwo section.
>>>
>>
>> For this one^ (& maybe this'd merge with 2a so it wouldn't need a
>> "supported platforms" check) the thing would be to print the non-dwo header
>> if both sections are empty, otherwise print the headers only for the
>> non-empty ones. I mean I guess that'd be a bit weird if you ask for
>> debug_types on a .dwo file and that file happens to not have type units
>> enabled & it prints the non-dwo name)
>>
>>
>> I'm having trouble parsing this. What would you like the behavior for
>> `llvm-dwarfdump --debug-types file.dwo` to be if (1) file.dwo has no
>> .debug_types.dwo section and no .debug_types section, (2) if it has only
>> the .debug_types.dwo section?
>>
>
> My suggestion was:
>
> 1) debug_types
> 2) debug_types.dwo
>
> but I was acknowledging that (1) could be confusing to users. I mean could
> detect that it's a .dwo file and so expect debug_types.dwo, but that's
> probably a pain from a layering perspective.
>
>
> (How) can I detect that we are dealing with a .dwo file other than looking
> at the filename?
> -- adrian
>
>
>
>>
>> -- adrian
>>
>>
>>
>>>
>>>
>>> https://reviews.llvm.org/D37771
>>>
>>> Files:
>>>   include/llvm/BinaryFormat/Dwarf.def
>>>   include/llvm/DebugInfo/DIContext.h
>>>   include/llvm/DebugInfo/DWARF/DWARFContext.h
>>>   include/llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h
>>>   include/llvm/DebugInfo/DWARF/DWARFDebugFrame.h
>>>   include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h
>>>   include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
>>>   include/llvm/DebugInfo/DWARF/DWARFUnitIndex.h
>>>   lib/DebugInfo/DWARF/DWARFContext.cpp
>>>   test/DebugInfo/Inputs/gmlt.ll
>>>   test/DebugInfo/X86/fission-inline.ll
>>>   test/DebugInfo/X86/fission-no-inlining.ll
>>>   test/DebugInfo/X86/fission-ranges.ll
>>>   test/DebugInfo/X86/generate-odr-hash.ll
>>>   test/DebugInfo/X86/gnu-public-names-gmlt.ll
>>>   test/DebugInfo/X86/live-debug-variables.ll
>>>   test/DebugInfo/X86/split-dwarf-cross-unit-reference.ll
>>>   test/DebugInfo/X86/split-dwarf-multiple-cu-hash.ll
>>>   test/DebugInfo/X86/split-dwarf-omit-empty.ll
>>>   test/DebugInfo/dwarfdump-dump-flags.test
>>>   test/MC/ARM/dwarf-asm-multiple-sections-dwarf-2.s
>>>   test/MC/ARM/dwarf-asm-no-code.s
>>>   test/MC/ARM/dwarf-asm-nonstandard-section.s
>>>   test/MC/ARM/dwarf-asm-single-section.s
>>>   test/tools/dsymutil/X86/basic-linking-x86.test
>>>   test/tools/llvm-dwp/X86/empty.test
>>>   test/tools/llvm-dwp/X86/simple.test
>>>   tools/llvm-dwarfdump/llvm-dwarfdump.cpp
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170913/ea0e254f/attachment.html>


More information about the llvm-commits mailing list