[Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

[David Blaikie]

On Mon, Jul 8, 2024 at 2:18 PM David Blaikie <dblaikie@gmail.com> wrote:

> Hi Matthew,
>
> I'm looking into your issue & I have some broad questions:
>
> This seems like it'd speed up generics-heavy code, to be sure - though I
> assume you hit a perf issue in some prototype tool already, that lead you
> to this issue? Do you have further details on the tooling you've
> prototyped/the problems you've encountered? Or is this proposal more based
> on an assumption/predicted issue?
>
> Also, while I imagine this feature could simplify the situation even when
> there aren't shared lines/generics (by centralizing the place to update) -
> I wouldn't've thought a naive... oh, I see, there's no "reset the line
> number".
>

I was slightly mistaken here - while looking at somewhat related work here
https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434/20
I
realized that end_sequence does reset the line number and other state in
the line table.

So here's my proposal: Have your compiler create a separate sequence for
each function, and have the sidetable data store a reference to the offset
of the special opcode that increments the line number immediately after the
end_sequence. Update that opcode as needed to represent the new line offset
when performing incremental recompilation.

This should be O(concrete functions) which presumably the operation is
already, in terms of updating the debug_info DIEs too (which is O(concrete
and inlined) functions, so probably dominates things anyway?)


> So even between sequences there's no resetting of the line number, so you
> can't just look for the line at the start of some functions, etc.
>
> Equally, though, putting some otherwise "random" line numbers in a list in
> the header of the line table doesn't seem like a generally usable feature -
> It'd be unclear how the DWARF modifying-tool would know which line numbers
> to update (couldn't rely on unique numbers - they might collide between
> different files, and some files might need updating and some not, etc)
>
> @Adrian Prantl <aprantl@apple.com> and @Jonas Devlieghere
> <jdevlieghere@apple.com> with the CAS DWARF stuff, how are you folks
> separating line table fragments for functions? My understanding was the
> line table header was too large to have one on every function's line table
> fragment, so I would've thought you'd figured out a way to make line table
> fragments that could be added/removed from a line table without disturbing
> the other flags/state and without relying on specific values in/out of the
> line register?
>

Yeah, nevermind this question, now I've fixed my mistake about separate
sequences, it makes sense - Apple/MachO is already doing the equivalent of
-ffunction-sections, which involves separate sequences for separate
functions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240722/af0f3fa6/attachment.htm>