[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-23 17:33:54 UTC ---
> The aim of the extension is to allow correct debug info, not almost correct,
> so I think defining "upon entering of the current subprogram" as anything but
> before the first insn in it is wrong and would make it not possible to use
> DW_OP_GNU_entry_value before the point (end of prologue or what?).

Yes, end of the prologue.  I was under the impression that, with your alternate
scheme, the opposite situation would arise, i.e. it wouldn't be possible to use
DW_OP_GNU_entry_value after the end of the prologue.  Given how GDB works, this
sounded far less appealing than the current scheme.  Sorry if I misunderstood.

> As for teaching var-tracking about save/restore on SPARC, it would be a matter
> of adding probably two target hooks, one that would be run e.g. at the end of
> adjust_insn and would be supposed to change it using validate_change (...,
> true); in whatever way var-tracking should understand the insn.
> So e.g. for save you'd add into the parallel things like:
>   (set (reg:P 24) (reg:P 8))
>   (clobber (reg:P 8))
> and similarly for all the other param regs.  Perhaps even make it explicit
> what exactly is subtracted from %sp.
> And the second target hook would return a different rtx for DECL_INCOMING_RTL,
> with registers adjusted back.  Because for -O0 if we don't do var-tracking we
> probably want DECL_INCOMING_RTL to still refer to %i0 etc., even when it is
> not correct before the save.

I see, thanks for the explanation.