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. > When you change signature of a function, it is no longer the original, it is > some modified copy (clone) of that, so that is how it should be represented. > Now, either you also emit the function with unchanged signature (e.g. if it > is not TU-local function but the compiler wants to optimize it anyway), or > don't. And, there doesn't need to be just one clone, there can be several, > e.g. several callers pass the same constant to one argument, so that argument > can be optimized away in the clone, but other callers pass constant to a > different > argument or the argument is needed by the callee or cloning can be done > based on interprocedural value range propagation etc.
Thanks. I will go back to revisit this option again. > Anyway, from what you've posted, i.e. that DW_OP_piece 8 DW_OP_reg rsi > DW_OP_piece 1 > etc. you can see the first 8 bytes of the structure are <optimized out> and > in where is the last byte passed in. There are ways to get value also in > some cases from DW_TAG_call_site information if you can prove what the > caller is, but if it is not passed, it will be always a best effort, > sometimes there is no way to find out the argument value that wasn't passed. I would prefer to implement a true signature in llvm since we do not need to deal with different architectures when processing dwarf. Currently, in llvm, I am able to find out all changed signatures based on dbg_* instructions for linux kernel I am targeting. Indeed for some cases (e.g. -O3), compiler did more aggressive optimization and indeed in some cases true_signature with correct semantics is very hard to find. See one of example in https://github.com/llvm/llvm-project/pull/165310 > > Jakub > -- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
