On Tue, Mar 9, 2021 at 3:40 PM Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Mar 09, 2021 at 03:22:35PM -0800, David Blaikie wrote: > > So, when the consumer evaluates DW_OP_GNU_parameter_ref, it handles it > > > similarly to DW_OP_entry_value, unwinds to caller if it can identify > it, > > > and just looks up if some value is specified for it in that particular > > > caller. > > > > > > > Could you help me understand more how DW_OP_GNU_parameter_ref > > works/differently from DW_OP_entry_value? > > DW_OP_entry_value refers to a register or memory in which a parameter > is passed. When a parameter is not passed at all, there is no register or > memory to which it can refer to. So, DW_OP_GNU_parameter_ref instead > refers to the DW_TAG_formal_parameter DIE and the consumer needs to find > a DW_TAG_call_site_parameter that refers to the same DIE. > Ah, OK. Hmm - do you have different call_site_parameters for registers versus parameters? Or I guess a call_site_parameter without a DW_AT_location and only a DW_AT_call_value? > > I think GCC doesn't do that, instead it would if considered beneficial > > > copy the function to a non-exported one and optimize away the > parameters in > > > there (etc.). > > > > > > Ah, OK - in which case there would be no DWARF for the copy? And the > > original function would look as though it were "optimized away" (ie: not > > have any DW_AT_low/high_pc, etc)? > > No, there is DWARF for the copy. The original user function is the > abstract > origin and then it has two (or more) DW_TAG_subprogram DIEs that refer to > that (and refer to DW_TAG_formal_parameter and DW_TAG_variable etc.) in it. > Hmm - is that "conforming" (I'm all for "DWARF provides some tools and here's a way we can use them to describe this situation") DWARF? I would've thought that there could only be one concrete instance of an abstract definition. And given that, could the user call this function from their debugger, and how would the debugger get the ABI correct? (let's say there were no other callers in other files - and we used gc-sections to optimize away that original external copy, perhaps - if that makes a difference) I guess since GCC didn't use the original symbol name, maybe the debugger wouldn't consider the modified copy to be a valid target to call the original function even though the DWARF says this is an instance of the original function? To come back to the original question - are there gaps between DWARF and the ABI, I think the answer is yes (for internalized functions), certainly for LLVM but I think for GCC too. At least in terms of what's guaranteed/explicitly communicated - we might have to formalize some things to make clear what conclusions can be reached when certain parameter locations are used. As it is today, DWARF doesn't guarantee that the DW_AT_location of a variable has no bearing on the way the function is called - even a DW_AT_location that doesn't use a location list only has to be valid after the prologue - so you can't guarantee that the location can be used for the calling the function (the simplest example of this is at -O0, you get nothing about how to call the function - but this DWARF would be ambiguous with an optimized build that took the parameter from some non-ABI register in the prologue and moved it into fbreg) - is that correct? Have I misunderstood something? - Dave
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org