http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.03.22 20:34:34
Ever Confirmed|0 |1
--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-22
20:34:34 UTC ---
> For SPARC, my preference would be if DW_OP_GNU_entry_value contained the
> output regs, after all when it is defined as value at the start of the
> function (== put a breakpoint on the very first insn and use value of that
> register), then the parameters are passed in %o[0-5] registers rather than
> %i[0-5].
That depends on what you call the start of the function though. Doesn't GDB
put the breakpoint at the end of the prologue (in fact 2nd loc directive) when
you say "break my_function"? There the arguments are in %i[0-5] already.
> And I guess the gdb changes should then magically work when using
> DW_TAG_call_site info - it will just look up the same registers with no
> translation. OT, seems if we wanted to be exact we'd need to model the
> register window save/restrore insns in var-tracking adjust_insn and start in
> vt_add_function_parameter with the outgoing regs instead of incoming that are
> in DECL_INCOMING_RTL.
> Current SVN trunk uses %i* instead of %o* in DW_OP_GNU_entry_value operands
> and %o* registers in DW_AT_location of DW_OP_GNU_entry_value.
"DW_AT_location of DW_TAG_GNU_call_site_parameter" I presume?
I think that the current situation is consistent with what we do at -O0, i.e.
home the arguments onto the stack in the prologue and emit a single location
for them in the debug info, the location in the stack. This yields correct
results with GDB because of the 2nd loc directive trick.
Of course you have a small window of invalidity (we got complaints about it at
AdaCore from folks working on other debuggers) so modeling the register window
instructions would indeed be better. Would that be hard to do?
