On Fri, Jan 16, 2026 at 10:03 AM Frank Ch. Eigler <[email protected]> wrote:
> Hi - > > > > Thanks. Now let us say I will not try to add those "changed function > > > signatures" to dwarf > > > and actually rely on dwarf locations to somehow recover parameters. > > > > > > That isn't possible, so far as I can see - DWARF only describes how to > > access the parameters from inside the function, not how they were passed > on > > the call. > > At the moment of entry to a function, those are the same thing. > > > (eg: an unoptimized build will probably describe the parameters > > as being in stack memory even though the values were passed in registers > - > > because the prologue moves the values from registers to memory, and the > > DWARF locations only have to be valid after the prologue) > > That sounds like a quality of implementation issue. Higher quality > compilers accurately note the location of parameters, as they change > within and after the prologue and other points in the function. It > is a location LIST after all. > Ish. Certainly it's possible to do that - do you have pointers to any compilers that do that? My experience with GCC and Clang at least has been that there's (perhaps an undocumented) understanding that the locations are only considered to be valid after the prologue/before the epilogue, and so it's more efficient in terms of DWARF disk space to only describe that area. > > > I actually want to ask how to identify whether the return type is > > > changed or not in dwarf. > > > [...] > > https://dwarfstd.org/issues/221105.1.html in DWARFv6 might help provide > > some of this information & is closer to an ABI-encoding than we have for > > parameters. > > This will be lovely. > > > - FChE > >
-- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
