[llvm-dev] [DWARFv5] The new line-table section header

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 27 13:12:04 PDT 2017

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.

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:
    DW_LNCT_path, DW_FORM_string
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 DW_FORM_strp
which puts the actual string in the .debug_string section; eventually we
could have DW_FORM_line_str (pointing to .debug_line_str) or even
DW_FORM_strx (indirecting through .debug_str_offsets).

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 .debug_info
section, and picks up its relocations from a DWARFUnit.  But if we're
using DWARFFormValue to decode data from .debug_line, then it needs a
different relocation map.

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 
DW_FORM_string for the paths.  This should let me use an unmodified 
DWARFFormValue to parse the directory and file tables.

>From there, teaching DWARFFormValue to handle DW_FORM_strp from the
.debug_line 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 line_str and strx<N> forms
would not require much additional effort.  Actually Wolfgang is
separately working on the strx<N> forms so with any luck that would
Just Work for the .debug_line 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 DW_FORM_strp from .debug_line up front,
but I think we might rather go at this in smaller pieces.


More information about the llvm-dev mailing list