This is the mail archive of the
mailing list for the GCC project.
Var-tracking generates broken DW_AT_frame_base on s390
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: gcc at gcc dot gnu dot org
- Cc: zlomekj at suse dot cz
- Date: Mon, 21 Jun 2004 14:24:25 +0200 (CEST)
- Subject: Var-tracking generates broken DW_AT_frame_base on s390
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
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?
Dr. Ulrich Weigand