On Sun, Jan 4, 2026 at 9:46 AM David Blaikie <[email protected]> wrote: > > > > On Thu, Dec 4, 2025 at 10:32 AM Jakub Jelinek <[email protected]> wrote: >> >> On Thu, Dec 04, 2025 at 10:10:10AM -0800, Y Song wrote: >> > > DW_OP_GNU_parameter_ref is an extension, see >> > > https://dwarfstd.org/issues/230109.1.html >> > > In any case, I don't see why you need something like >> > > DW_TAG_inlined_subroutine at DW_TAG_compile_unit scope, you can't inline >> > > a >> > > function into a translation unit. >> > >> > Thanks. This is indeed an option. See >> > https://github.com/llvm/llvm-project/pull/157349#issuecomment-3412590751 >> > But lldb has some concerns since it change the *existing* output >> > during lldb debugger. >> > See the above link. >> > >> > Do you have better suggestions or have a way to make lldb people okay with >> > it? >> >> GCC has been emitting it this way for at least 15 years, so lldb better >> handles it. > > > (I think there's some misunderstanding/miscommunication here) > > Your proposal, Jakub - was that a signature-modified function be emitted as a > concrete instance of an inlined function. It can be, and lldb can handle > that, but I'm not sure what information that's intended to convey to a > consumer that's different from emitting the function as a single concrete > function without an abstract origin? Could you clarify? (& I don't think it > addresses their claimed need (which I think needs more discussion to see if > the claim is valid, maybe there are other solutions to consider, > https://en.wikipedia.org/wiki/XY_problem and all that) to know the new > signature of the function - DWARF location expressions aren't guaranteed to > describe the ABI of a function, only where to find the value of the > parameters after the prologue (if a location is provided/available at all, > which is a quality of implementation thing - so they might not even describe > that) - they might omit parameters that have no use/have been clobbered even > though they are part of the ABI of the function, they might describe > parameters in stack memory or other registers because they've been moved in > the prologue, etc)
It would be great if a concrete example can be shown to have both original signature and changed signature... > > But Y Song's thing is that they prototyped emitting signature modified > functions as a distinct function - the proposal here is to have a > DW_TAG_inlined_subroutine that isn't inside any other subprogram, and that's > the original source version of the function, then a concrete > DW_TAG_subprogram with the signature-modified/lowered version of the > function. Which is pretty novel so it's not too surprising debuggers aren't > really ready to handle that. (at least that's my best understanding at the > moment - totally possible I've misunderstood) Thanks, David. Is it possible to have a separate CU to host functions with changed signatures? Those signature changed functions can have a scope to the original abstract origin. This way, we do not need to have DW_TAG_inlined_subroutine to encode signature-changed functions. WDYT? -- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
