This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: varobj's find_frame_addr_in_frame_chain hack (and other ARM unwind notes)


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).

> - 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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]