This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Mar 2011 16:45:18 -0000
- Subject: [Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets
- Auto-submitted: auto-generated
- References: <bug-48220-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-23 16:45:05 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?).
Consider e.g. shrink-wrapping Bernd just proposed for GCC too...
So I think what we currently do on SPARC has to change.
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.