This is an archive of the discontinued LLVM Phabricator instance.

Add support for DebugFission to DWARF parser
ClosedPublic

Authored by samsonov on Jul 17 2013, 5:14 AM.

Details

Summary
  1. Make llvm-symbolizer properly symbolize

files with split debug info (by using stanalone .dwo files).

  1. Make DWARFCompileUnit parse and store corresponding .dwo file,

if necessary.

  1. Make bits of DWARF parsing more CompileUnit-oriented.

Diff Detail

Event Timeline

Oh, and I would appreciate advice on writing tests for split-dwarf. Looks like debug info in the binaries built with -gsplit-dwarf always contains absolute paths to .dwo files, so checking in pre-built binaries is problematic... Generating .dwo files requires a fresh enough objcopy. Also, building binaries from source (or bytecode) in test cases would make it hard to predict the resulting object file layout and build (input, expected output) pairs for llvm-symbolizer...

Totally missed this. I'll look today. Sorry about that.

Few questions inline, otherwise looks pretty good.

include/llvm/DebugInfo/DIContext.h
127 ↗(On Diff #2864)

Unfortunate naming in english. How about CK_DWARF?

lib/DebugInfo/DWARFContext.h
30 ↗(On Diff #2864)

Consider breaking this part out first in a separate patch? Also, since there's a single DWO for a single compile unit I'm not sure about the change to pointer as far as relevance to this patch. Can you give a bit more explanation here?

samsonov updated this revision to Unknown Object (????).Aug 6 2013, 4:28 AM

Reduced version of the patch.

I've commited minor parts of this patch as r187790, r187792, and mailed http://llvm-reviews.chandlerc.com/D1298 separately.

include/llvm/DebugInfo/DIContext.h
127 ↗(On Diff #2864)

Done (RTTI part commited in r187790).

samsonov updated this revision to Unknown Object (????).Aug 6 2013, 4:38 AM

Remove obsolete debugging code.

echristo accepted this revision.Aug 22 2013, 11:47 AM

This is fine. I'm not really happy with the IsDWOIndex and might want to just put the form type in, but I'm not wedded to either idea. Thanks.

samsonov closed this revision.Aug 27 2013, 2:22 AM
In D1164#1, @samsonov wrote:

Oh, and I would appreciate advice on writing tests for split-dwarf. Looks like debug info in the binaries built with -gsplit-dwarf always contains absolute paths to .dwo files, so checking in pre-built binaries is problematic... Generating .dwo files requires a fresh enough objcopy. Also, building binaries from source (or bytecode) in test cases would make it hard to predict the resulting object file layout and build (input, expected output) pairs for llvm-symbolizer...

Rafael recently (temporarily) broke some of this code while doing some unique_ptr refactoring and we were both a bit surprised by the lack of test coverage. You make a good point though, that this isn't easy to test, but let's see if there's some way:

What would happen if we build a dwo file somewhat manually - generating the assembly from Clang/LLVM, then hand-hacking the dwo file path (or just using clang -cc1 and specifying the dwo file name manually) as a relative path, rather than an absolute one. Would that produce a reusable test case we could commit to the lit suite?

Otherwise, at least, it'd be useful to have some manual test steps written down somewhere (maybe in the test/ directory, just in the form of a text file with a FIXME and manual steps).

Right, I was able to forge the test case by hacking -fdebug-compilation-dir in clang-cc1 invocation. The fix by Rafael was incorrect, and I had to debug nasty memory corruption (ASan FTW). Which is one more proof of "never-compromise-the-testing" rule. Sigh.