This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: varobj's find_frame_addr_in_frame_chain hack (and other ARM unwind notes)
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 30 Jun 2003 23:38:28 -0400
- Subject: Re: varobj's find_frame_addr_in_frame_chain hack (and other ARM unwind notes)
- References: <20030630170034.GA18829@nevyn.them.org> <3F0089CA.1080704@redhat.com> <20030630191147.GA29248@nevyn.them.org> <3F00D7C8.5040704@redhat.com>
On Mon, Jun 30, 2003 at 08:37:28PM -0400, Andrew Cagney wrote:
> >On Mon, Jun 30, 2003 at 03:04:42PM -0400, Andrew Cagney wrote:
> >
> >>>varobj.c:find_frame_addr_in_frame_chain, and mi-var-display.exp. We
> >>print
> >>>out $fp, and use then search for that value in the frame chain. Well,
> >>>the DWARF-2 CFA value on ARM is biased from the frame pointer register,
> >>>generally by four bytes. I chose to use the same thing in the prologue
> >>>unwinder for consistency - it makes unwinding ARM_SP_REGNUM simpler,
> >>which
> >>>we need to get right in order for dummy frames to work.
> >
> >>
> >>Two wrongs, and they don't make a right :-(
> >>
> >>- the arm shouldn't be setting / forcing FP_REGNUM
> >>Instead, "fp" should always be the frame base.
> >
> >
> >$fp refers to a particular register on ARM. Are you saying that print
> >$fp should print the frame base, and not the contents of the frame
> >pointer register? Personally I'd find that pretty surprising. Sure,
> >call it $frame if you want, but $fp is expected to be $r11 (in ARM
> >mode).
>
> If the ISA has a register called $fp then $fp prints that register's
> value, else, $fp prints the `frame base' (which should be `frame locals
> address'). There's also a change-request open for someone to check that
> the Arm really does follow this behavior (compare `info registers fp'
> with `print $fp').
>
> Anyway, the upshot is that, for scripting purposes, $fp is useless.
>
> There is my patch to add $frame or $gdb.frame kicking around.
>
> >>- the test shouldn't be using $fp to re-find a frame
> >>It should be using a frame ID, but that involves interface changes to
> >>the MI -> MI 4.
>
> >So.... what, should I just ignore the failure or should I make the
> >get_frame_base_address change?
>
> Unless you're up to revamping the MI interface so that it takes frame
> IDs ... :-).
Maybe after I'm done with the rest of this TODO list :-) They tell me
it has a bottom somewhere in Timbuktu.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer