To my knowledge there is nothing in DWARF to capture this, but tools can use additional platform-specific information in addition to DWARF to provide a richer experience. For example, LLDB can display both the real call stack (from unwinding+DWARF) and the virtual call graph (by following coroutine records using domain knowledge outside of DWARF) for Swift asynchronous functions.
-- adrian > On Dec 27, 2023, at 6:55 PM, Eleanor Bartle via Dwarf-discuss > <dwarf-discuss@lists.dwarfstd.org> wrote: > > Everything I know about unwind info seems to suggest only a single previous > frame can be referenced (the single CFA in particular). However, in languages > with coroutines, there could potentially be two "previous" frames: the > procedure it will yield to, and the coroutine awaiting on it. Zig in > particular has stackless coroutines, and the primary specification writer > once talked about making the coroutine context object a "stack" internally, > then storing a pointer into this stack in the frame pointer register so > unwinding would give the call sequence of coroutines. > > I was wondering, is there a way within the current DWARF specification to > capture this graph bifurcation? It seems strange to me that DWARF is so > incredibly flexible and adaptable, yet this one thing is beyond that reach. > Would we really have to generate two sets of tables? Is that even possible > without breaking all the tools? > > Obviously this is a low-priority message. > Eleanor > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org <mailto:Dwarf-discuss@lists.dwarfstd.org> > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
