This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: jan dot kratochvil at redhat dot com (Jan Kratochvil)
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 13 Oct 2011 16:59:37 +0200 (CEST)
- Subject: Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011
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