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

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

           Summary: DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter
                    vs. register window targets
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org


I haven't thought too much about register window issues when designing this
extension, so it would be good to decide what exactly to do for such targets.

Let's start with some testcases:

__attribute__((noinline, noclone))
void fn1 (long int x, long int y, long int z)
{
  asm volatile ("" : : "r" (x), "r" (y), "r" (z) : "memory");
}

__attribute__((noinline, noclone)) long int
fn2 (long int a, long int b, long int c) 
{
  long int q = 2 * a;
  fn1 (5, 6, 7); 
  return 0;
}

long int
fn3 (long int x, long int (*fn4) (long int *))
{
  long int v, w, w2, z;
  w = (*fn4) (&w2);
  v = (*fn4) (&w2);
  z = fn2 (1, v + 1, w);
  {
    int v1 = v + 4;
    z += fn2 (w, v * 2, x);
  }
  return z;
}

int
main (void)
{
  return 0;
}

and testcase from http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html

While GDB support has been written for these extensions on
http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval
I bet it hasn't been tested on sparc/ia64/and other register window targets
yet.

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].
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.

IA-64 is more challenging.  On SPARC just the save/restore insns are relevant
to the register windows, while on IA-64 both br{,l}.call and alloc insns.
With the definition that DW_OP_GNU_entry_value should be defined as put a
breakpoint on the very first insn in a function, remember register values there
I'd say thus that DW_OP_GNU_entry_value should reference r32/r33/etc. regs. 
The question is what should be used in DW_AT_location of
DW_TAG_GNU_call_site_parameter.  Either it can be the state on the br.call insn
itself (which would mean they are the outN registers mapped accordinly to the
hard register numbers given the current alloc insn), or after the call insn is
executed (then we'd need to map the outN registers to the inNs).
The first option would mean more work for the debugger on IA-64, it would need
to map the outNs to inS, but perhaps is more in line with the proposal that
DW_TAG_GNU_call_site_parameter lists the location at the call.  And it would
require no changes to GCC.  The other option would mean less work for the
debugger, but GCC would need to map the parameter registers in
prepare_call_arguments using INCOMING_REGNO for ia64.  If we go this route, the
question is if registers mentioned in DW_AT_GNU_call_site_value etc. shouldn't
be remapped too, so I very much prefer the first variant for IA-64 if it can be
implemented.