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

[Daniel Jacobowitz <drow at mvista dot com>]

I've got a working port of ARM to the new frame code, which I'll post in an
few hours.  I just need to clean it up a little bit, and figure out what to
do about the new failures.  One in particular is bugging me, so I have two
questions:


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.

As a result the search through the frame chain fails.  If I define an
appropriate frame_base unwinder to return the start of the frame, and I hook
that in, and change the get_frame_base call in varobj.c to
get_frame_base_address, then it works.  This code is pretty bogus, but it
seems to me that (for now at least) get_frame_base_address is correct there. 
Would a patch to correct that be reasonable?



Then when I hook in the DWARF-2 unwinder in a later patch, it fails again if
I hook in dwarf2_frame_base_p.  It seems to me that a frame base mechanism
which returns the CFA is worse than useless, and the comment above that
routine agrees.  It also seems to me that we should have a dwarf frame base
mechanism which returns DW_AT_frame_base, but that will take a little bit of
work in the DWARF-2 reader... does anyone disagree with changing
dwarf2_frame_base_p to use .debug_info if present, instead of .debug_frame
if present?




Other current issues, if you're curious:

The old code was (completely incorrectly!) deciding that _start had a frame
register of ARM_FP_REGNUM in asm-source.exp.  This caused it to return 0
from arm_frame_chain, because _start clears $fp.  The new code correctly
realizes _start does not have a traditional frame, and returns its saved
$sp instead.  We loop. I may just detect the loop to stop... the alternative
is to be much more liberal about deciding that the function has a frame
pointer.  More on this later.

Using the DWARF-2 unwinder adds six failures in store.exp.  Don't know why
yet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer