Re: [RFA/ARM] Framificate the ARM port [3/3]

[Andrew Cagney <ac131313 at redhat dot com>]

> Makes sense.  I will need to cache a PC to fix some corner cases with
> signal trampolines, but I'm not fixing that bug right now.

Can you expand?  I can understand cacheing the previous frame's PC but 
not this frame's.


> > >+/* Assuming NEXT_FRAME->prev is a dummy, return the frame ID of that
> > >+   dummy frame.  The frame ID's base needs to match the TOS value
> > >+   saved by save_dummy_frame_tos(), and the PC match the dummy frame's
> > >+   breakpoint.  */
>
> > ... tos() and returned by arm_push_dummy_call.
>
>
> Copied this comment verbatim from three other implementations.  You
> might want to update those.

Sigh!  Code is breeding again ...

> > >+/* Given THIS_FRAME, find the frame's resume PC (which will be part of the
> > >+   frame ID for THIS_FRAME's caller's frame).  */
>
> > Given THIS_FRAME, find the PREV frame's resume PC (which will be used to 
> > find the PREV frame's function and that in turn used to construct the 
> > PREV frame's ID).
>
>
> Eh?  Uch, I suppose.  "resume PC" is a bit ambiguous.
>
> The reason that I like my notation better is that I don't need to think
> about what "this frame's caller" means.  But every time I see NEXT or
> PREV I have to take five seconds to work it out.  Caller is
> unambiguous.

Don't forget that in the case of signal trampolines and sentinel frames 
there is no caller.

Older and younger work better but prev and next are what the dwarf2 spec 
and before that gdb, long ago, decided to use :-/

Andrew