DWARF generation
AbandonedPublic

Authored by scpmw on Oct 29 2014, 1:57 PM.

Details

Reviewers
simonmar
tibbe
austin
Trac Issues
#3693
Summary

This patch builds on top of D169, establishing DWARF generation for the NCG
x86 back-end.

This is split into three parts:

  1. Generation of line information (.debug_line)

    We are not directly generating DWARF, but instead instruct the assembler to generate it for us using .loc and .file directives. Getting them to to appear in the correct places means that we need to get into the guts of native code generation a bit - we especially need to keep track of what files we have declared so far.
  1. Generation of debug records (.debug_line)

    This is where we deposit information about the compiler, compilation units as well as source blocks. This is also where we assign Haskell names to things (sadly, most consumers straight-up ignore it right now because they don't recognise our language ID).
  1. Generation of unwind information (.debug_frame)

    This allows debuggers to unwind the Haskell stack. This is a bit more involved than it should be - mostly due to the fact that our stack doesn't really look the way debuggers expect. We especially can't promise that unwinding will work from any place that's not a block entry.

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Branch
profiling-arc-396
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 2643
Build 2654: GHC Patch Validation (amd64/Linux)
scpmw retitled this revision from to DWARF generation.Oct 29 2014, 1:57 PM
scpmw edited the test plan for this revision. (Show Details)
scpmw added reviewers: austin, simonmar, tibbe.
scpmw updated the Trac tickets for this revision.
scpmw updated this object.
austin requested changes to this revision.Dec 8 2014, 9:41 AM

OK, on a quick pass, this LGTM. Just please fix all the 80-col violations.

This revision now requires changes to proceed.Dec 8 2014, 9:41 AM
scpmw added a comment.Dec 8 2014, 9:43 AM

Yeah, I'll have to change a few things because of the changes in D169 anyway. Won't take too long, hopefully.

scpmw updated this revision to Diff 1921.Dec 10 2014, 5:04 AM

Made consistent with new revision of D169, fixed lint and corrected
yet another performance test.

scpmw updated this revision to Diff 1932.Dec 11 2014, 9:41 AM

Small fix - end label for procs with info table was wrong.

simonmar accepted this revision.Dec 15 2014, 10:20 AM

I haven't reviewed this in detail, but it's not likely to break anything and we want it in for 7.10.

Oh my, I can't believe I missed this patch set! Fantastic that this patch set is also reviewed and underway, good job!

I just have a small question, remember when we talked about using integers the size of Haskell's Int for line and column numbers instead of 16-bit Words? Does this patch set honor that?

By the way, how and when does the rts-code (like Dwarf.{c,h}) and stack traces come into the picture? I suppose Haskell-land stack traces won't make it in now as of the feature freeze. But put your thoughts down here before we forget about it. I thought of starting to rebase and submit patches once your patches are in. :)

scpmw updated this revision to Diff 1962.EditedDec 16 2014, 4:42 AM

Rebased, following D169.

scpmw added a comment.Dec 16 2014, 4:58 AM

@Tarrasch - this doesn't talk about line numbers explicitly at any point, we leave that to the assembler. You are probably referring to the .debug_ghc records, which aren't yet part of this.

We will probably have to put some more thought into the RTS portions before we can merge them - the libdwarf dependency is pretty troublesome. At this point I am pondering whether the right approach might be to attempt to use libbfd (like other parts of the RTS do) and build a (very) simple DWARF reader on top. This *might* allow us to remove one dependency and become more portable at the same time.

@scpmw This is now merged; you can also abandon this revision.

scpmw abandoned this revision.Dec 16 2014, 6:48 PM

(landed as multiple commits)

Awesome job on landing this. Hehe, will do a lot of rebasing during the christmas holidays then! :)

@scpmw So you're saying that libdwarf is a pretty heavy-weight dependency? Yes, I do remember it was a complete pain to compile your branch of GHC with stack traces. But do you think that we use such a small subset of libdwarf so that it makes sense to make our own minimal version with only the parts that we need? I never entirely understood the implementation details of your Dwarf.c, but do you imagine that we basically "replace" the libdwarf calls from there with our own methods?

Have you planned to work with DWARF reading in the RTS anytime soon? Is there anything I can help with?

scpmw added a comment.Dec 17 2014, 7:01 AM

I was referring to the fact that we can't link against it for most common distributions, as well as that it depends on libelf to the point that it's entirely useless on anything but Linux. The only realistic shipping option would be to ship a patched version, which is probably something we'd like to avoid.

And yes - we aren't using too much of it. Right now we're only reading .debug_info, which should be straightforward enough to parse. All we need is a portable way to get our hands on the contents of the .debug_abbrev and .debug_info sections.