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