From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb-patches@sourceware.org, jimb@codesourcery.com
Subject: Re: [rfc] Unwind the ARM CPSR
Date: Wed, 17 Oct 2007 00:30:00 -0000 [thread overview]
Message-ID: <200710162220.l9GMKmu1002397@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20071011145137.GA18336@caradoc.them.org> (message from Daniel Jacobowitz on Thu, 11 Oct 2007 10:51:37 -0400)
> 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?
next prev parent reply other threads:[~2007-10-16 22:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-11 14:59 Daniel Jacobowitz
2007-10-11 15:52 ` Daniel Jacobowitz
2007-10-12 8:08 ` Joel Brobecker
2007-10-16 22:09 ` Mark Kettenis
2007-10-17 0:36 ` Daniel Jacobowitz
2007-10-17 6:05 ` Daniel Jacobowitz
2007-10-17 13:18 ` Joel Brobecker
2007-10-19 11:54 ` Ulrich Weigand
2007-10-17 0:30 ` Mark Kettenis [this message]
2008-05-01 18:31 ` Daniel Jacobowitz
2008-05-01 18:35 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200710162220.l9GMKmu1002397@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=jimb@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox