[Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

[David Blaikie]

On Sun, Jul 21, 2024 at 3:54 PM Jacob Young <jacobly.alt@gmail.com> wrote:

> > On 12/07/2024 19:04, David Blaikie wrote:
> > > Thanks for all the context (I noticed you replied directly to me - are
> > > you happy/OK having this discussion on the mailing list, rather than
> > > in private? It'd help to keep all the history visible, linkable, etc)
> > Yes, apologies, that was just a mistake on my part -- I meant to do
> > this, then realised I accidentally replied to you directly, so went to
> > forward it to the list, and only now realised that I accidentally
> > forwarded it to a completely unrelated list :P
> > > While I can appreciate the desire to make this update O(N) in the
> > > number of source lines affected - would it be acceptable for this to
> > > be O(N) in the number of machine/object level functions?
> > >
> > > Like if we had a feature for resetting the line table program part-way
> > > through a line table - would that be adequate? Then your external data
> > > could keep track of the line number setting operation at the start of
> > > the new/distinct/indepednent sequence and update that?
> > While not ideal for us, this would certainly be an improvement. Dealing
> > with the relative line number offsets is definitely the biggest pain
> > point wrt constructing the LNP today.
> > > Such a feature would have some more generality/usefulness directly
> > > without external/side data - for instance it would make chunks of the
> > > line table discardable, which could make it easier for a producer to
> > > use comdats to isolate the line table data associated with an inline
> > > function and allow the linker to discard such a contribution if
> desired.
>
> My idea for solving this problem without additional side data is to instead
> add a line table opcode that references an existing DIE with DECL
> attributes
> and sets the state machine's line register to the value of its
> DW_AT_decl_line
> attribute.  Similarly, DW_AT_decl_file and DW_AT_decl_column could also
> be copied to file and column for consistency.  By itself, this doesn't
> reduce
> the number of updates required, but it could be combined with an additional
> DIE tag for representing the source decl before inlining/instantiation and
> a
> DIE attribute for referencing the source decl from the inlined/instantiated
> DIE which would indicate that DECL attributes are copied from the source
> decl.  That way, the DECL attributes would only ever need to be updated in
> a single place, the source decl DIE.
>
> Instead of creating a new tag, it also seems pretty straightforward to just
> reuse DW_AT_subprogram for the source decl.  Since uninstantiated
> functions would not correspond to any program addresses, a missing
> DW_AT_low_pc or new flag attribute could indicate this. The intended
> meaning of DW_AT_abstract_origin already links an inlined function to
> the source decl.  For instantiations, it's possible to add meaning to
> either
> DW_AT_abstract_origin or DW_AT_specification, or create a new attribute.
> Both of these existing attributes already indicate that the referenced DIE
> contains some of the attributes of the referencing DIE, but I am probably
> stretching the intended meaning of the latter too far for this particular
> use
> case.  (Actually, I wrote that reading DW_AT_abstract_origin as being only
> documented as related to inlined functions, but I see now that it
> explicitly
> "can be used with almost any debugging information entry" and the name
> already seems to me to fit this instantiation use case perfectly.)
>
> I should note that I'm already in the process of considering whether new
> tags/attributes will be needed, some to support incremental, and some to
> support Zig Language concepts that do not exist in DWARF yet.  It seems
> likely that at least some number of new definitions will be needed anyway,
> and I would expect that being able to represent source decls in a separate
> DIE with references from the generated decls is useful independently of
> whether this proposed line table opcode is accepted.  (Although with my
> newfound understanding of DW_AT_abstract_origin, I'm now back down
> to only one new DIE tag and one new DIE attribute to support incremental.)
>
> I'm sure this could easily be converted into a more concrete proposal,
> but I am interested in getting some feedback first, since I don't know if
> there are any pre-existing constraints preventing .debug_info from being
> referenced from .debug_line.  As I hope I have demonstrated, this seems
> much more extensible to new use cases than the previous proposal.
>

Yeah, that'd be the tough part - currently the line table doesn't reference
anything in debug_info, and that's both beneficial in some ways (means you
can strip everything but the line table and still get symbolized stack
traces (& we added debug_line_str and some other changes to make this more
feasible in DWARFv5)) and just trickier to implement (the line table is
created by the assembler, but the debug_info is just arbitrary assembly
code created by the compiler - so having them reference each other beyond
that initial stmt_list reference is more complicated than other DWARF
features).

Sharing some info between template instantiations might be nice, but I'd
like to see an analysis/prototype of the savings to be gained - it'd
probably have to/likely go along with something like simplified template
names to allow sharing the base name between instantiations, but really I'm
not sure if all the extra DIE-to-DIE references would be cheap enough to
help with savings from whatever shared data there might be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240722/692ab167/attachment.htm>