Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011

["Ulrich Weigand" <uweigand@de.ibm.com>]

Jan Kratochvil wrote:
> On Thu, 13 Oct 2011 03:55:36 +0200, GDB Administrator wrote:
> > 216a217
> > > gdb/dwarf2-frame-tailcall.c:283: obsolete: get_frame_base: Replace get_frame_base with get_frame_id, get_frame_base_address, get_frame_locals_address, or get_frame_args_address.
> > gdb/dwarf2-frame-tailcall.c:283:	addr = get_frame_base (this_frame) - cache->entry_cfa_sp_offset;
> 
> This comes from my:
> 	[patch 04/12] entryval#3: Virtual tail call frames
> 	http://sourceware.org/ml/gdb-patches/2011-09/msg00556.html
> 
> where the code is specific to gdbarch_sp_regnum, so I think it should operate
> with this_frame->stack_addr, which is exactly what get_frame_base does.

Unfortunately this code reintroduced a number of platform-specific assumptions
that Andrew went to a lot of effort to eliminate from common frame-handling
code.  Generic code is not supposed to make the assumption that there *is*
a single "sp" (or "pc") register; instead it should leave the details up to
the gdbarch's unwind_pc and unwind_sp routines.  (And on various platforms
those routines *are* more complicated that just unwinding one particular
register ...)

I don't like re-introducing a new use of get_frame_base in common code;
we've been really close to eliminating this (for good reasons; see the
various comments in the code).  The problem is that frame->stack_addr
is supposed to be opaque to common code; it is explicitly *not* defined
to equal the value of some SP register.  It's meaning is solely up to
the frame unwinders.

For DWARF frames specifically, the convention is that ->stack_addr will
equal the CFA.  So if you are in DWARF-specific code, and need the CFA,
you can make use of that convention; but the best way to do that would
probably be to call dwarf2_frame_cfa instead of get_frame_base.

Note however, that even the CFA is not automatically equal to some "value
of a SP register"; for example, on s390(x), the CFA is always biased by 96
(or 160) bytes against the SP at function entry ...

> I understand such code ($sp simulation with shift for return address in tail
> call frames) could have been rather gdbarch-specific but I am not aware of any
> gdbarch where it should be done differently.  If such gdbarch exists and there
> is interest in fixing this very minor feature of the entryval patchset this
> can be moved to gdbarch-specific code where maybe get_frame_base may not be
> appropriate.  I have no idea without being aware of any such gdbarch.

I'm afraid I'm not sure exactly what all this SP manipulation code is intended
to achieve; could you elaborate (or is there documentation somewhere that I
missed)?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com