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) 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)
-- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
