[llvm-dev] [DWARFv5] The new line-table section header (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 28 12:10:21 PDT 2017

On Thu, Apr 27, 2017 at 1:12 PM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote:

The next feature on my DWARF 5 list is the line-table header. While this is pretty easy generate, it is a real bear to parse, so I thought I should let y'all know what I'm up to and why as I head out to the yak farm. Any thoughts and suggestions would be very much appreciated.

Thanks a bunch for sending this email! - I'd love to see more like this when large pieces are undertaken in LLVM for just these reasons, so we can all get a sense of where things are aiming, the motivation, etc.

The v5 directory and file tables no longer have a fixed format; instead, we have a list of field descriptors followed by the fields for each entry in the directory or file table. Normally the directory table would have one descriptor: DWLNCTpath, DWFORMstring This tells us each entry contains a pathname encoded as an inline string. (Which is essentially how the v4 directory table is encoded.) However, because of the FORM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DWFORMstrp which puts the actual string in the .debugstring section; eventually we could have DWFORMlinestr (pointing to .debuglinestr)

What's DW_FORM_line_str/debug_line_str for? (so the line table can be kept while strippnig the rest of the debug info, including its strings?)

or even DWFORMstrx (indirecting through .debugstroffsets).

Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form code is. Inconveniently, DWARFFormValue assumes it is looking at a .debuginfo section, and picks up its relocations from a DWARFUnit. But if we're using DWARFFormValue to decode data from .debugline, then it needs a different relocation map.

I'm going to assume there's going to be similar inconvenience on the other side (the emission side).

It's only the string data that causes a problem; all the other kinds of data in the file table are constants, and retrieving constants with DWARFFormValue is no problem.

I think the right tactic is a "top-down" approach, starting by teaching DWARFDebugLine to parse a v5 line-table header but support only DWFORMstring for the paths. This should let me use an unmodified DWARFFormValue to parse the directory and file tables.

Any idea what form you'll be using for LLVM's emisison? LLVM currently only emits strp - figure the same for the line table? Or more likely to use _string unconditionally?

In any case - if/when you have the right format support in llvm-dwarfdump, you could go ahead and implement the output code in LLVM's codegen, even before llvm-dwarfdump can handle every arcane format that any DWARF producer might decide to use. (& then you can continue implementing those - but it'd get you the LLVM functionality sooner, rather than gating it on having a fully general parser)

This approach has certainly been taken in the past - implementing enough dumping support as needed for LLVM's generation functionality & expanding as-needed.

From there, teaching DWARFFormValue to handle DWFORMstrp from the .debugline section should be pretty well motivated and it should be straightforward to see what's really needed in terms of the API.

Once we get that far, I would hope that the linestr and strx forms would not require much additional effort. Actually Wolfgang is separately working on the strx forms so with any luck that would Just Work for the .debugline section. Oh yeah, after all that I'd actually generate the v5 header from LLVM. The idea is that by then, I can use llvm-dwarfdump to validate it and be very confident that it would all work. Does all that sound like a plan? The alternative would be to try to teach DWARFFormValue to handle DWFORMstrp from .debugline up front, but I think we might rather go at this in smaller pieces. Thanks, --paulr

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170428/17521a14/attachment.html>

More information about the llvm-dev mailing list