Var-tracking generates broken DW_AT_frame_base on s390

[Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>]

Hello,

enabling var-tracking on s390(x) causes incorrect debug info to be emitted.
The problem is that GCC will emit a location list for AT_frame_base which
doesn't fit the way the frame base is used to describe local variables;
the effect is that every on-stack variable is not found at its correct
location.

The way the stack is layed out on s390 is as follows:  after function
entry, the prolog code subtracts from the stack pointer (%r15), allocating 
a stack frame.  All local variables are accessed using positive offsets 
relative to %r15, which remains constant throughout the function (until 
the epilog).  The exception are functions that use variably-sized stack 
allocations; these function will set up a frame pointer (%r11) at the end 
of the prolog, and will access all local variables using that register.

This causes the GCC middle-end to describe variable locations as (%r15 + X)
or (%r11 + X)  (depending on frame_pointer_needed).  The DWARF-2 code 
transforms this to 'DW_OP_fbreg X', i.e.  frame-base + X.  For this to work
requires the frame base to be set up to point to the value of either %r15
or %r11 *after* the prolog.

The old (non-vartracking) GCC DWARF-2 code would in fact achieve this by 
emitting a DW_AT_frame_base that points to either stack_pointer_rtx or 
hard_frame_pointer_rtx.  At the time GDB would evalute that info, we were 
already past the prolog, and hence GDB would retrieve the correct value of 
the register in question (and thus have the correct frame base).

However, the new var-tracking code tries to be clever and emits a location
list for DW_AT_frame_base itself.  In doing so, there appears to be the
hard-coded assumption that the frame base must be identical to the value
of the stack pointer at function entry.  The var-tracking code traces the
prolog RTX and notices the insn that subtracts from the stack pointer; 
from that point on, the frame_base location is then represented as 
(%r15 + frame-size), which is clearly wrong for s390.

Any ideas how to fix this?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de