This is the mail archive of the gdb-patches@sourceware.org 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: [rfc] Unwind the ARM CPSR


> Date: Thu, 11 Oct 2007 10:51:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Most of CPSR is not saved by normal function calls.  But the nicest
> way by far to handle Thumb-ness checking for frames is to unwind that
> frame's CPSR and check its T (Thumb state) bit, which requires the
> unwinders to synthesize a saved CPSR from the next frame's CPSR
> and the saved return address.  Pretty straightforward for the prologue
> unwinder, but harder for the DWARF-2 frame unwinder.

Yeah, DWARF-2 doesn't really have the concept of bit-fields.

> To handle that, I added a new DWARF2_FRAME_REG_FN which supplies a
> default unwinder.  For the PC, I originally added
> DWARF2_FRAME_REG_RA_MASK instead to mask out the low bit, but
> that wasn't enough for the CPSR.  And I discovered that
> there is no easy way, given the arguments to an unwinder's
> prev_register method, to request the unwound value of another
> register from the same frame!  That's why the patch below had
> to make dwarf2_frame_prev_register global, and pass its opaque
> THIS_CACHE to the function supplied by DWARF2_FRAME_REG_FN.

Two remarks:

1. Isn't this function always going to return a plain value?  That
   means we can probably simplify the register.

2. Perhaps the function should get passed the unwinder struct, such
   that it can use the function pointer.

> During a prev_register method there are three frames of interest.  The
> NEXT frame is passed; the CURRENT frame's cache is passed and some
> knowledge of the CURRENT frame is implicit in the called function; and
> the PREVIOUS frame's register value is calculated.  Given a frame
> there are functions to get its register values or the values of the
> previous frame; since we start with NEXT that means we can use generic
> frame interfaces to get only NEXT or CURRENT registers.  But to
> calculate PREVIOUS's CPSR we need PREVIOUS's LR so we have to call
> dwarf2_frame_prev_register directly.

I think this means that making the unwinder reconstruct CPSR may not
be the right approach.  Isn't it better to determine thumbness based
on the unwound LR?  That should work for all frames, except the
topmost.  But for the topmost frame we should be able to trust CPSR.

I also see that you treat unwinding the PC specially in the unwinders,
to strip off bits.  But isn't that why we have the unwind_pc gdbarch
method?


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