This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Problem converting ia64 to use new frame model
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 09 Jul 2003 11:25:27 -0400
- Subject: Re: Problem converting ia64 to use new frame model
- References: <3F09F0A3.6020201@redhat.com> <3F0B48FF.3000700@redhat.com>
First take a look through: WIP: Register doco
http://sources.redhat.com/ml/gdb/2002-07/msg00202.html
It's now a bit dated but the basics still apply
I am having problems converting the ia64-tdep.c file to use the new frame model.
The main problem stems from the fact that the next frame is asked for the current
registers. When dealing with the innermost frame, the sentinel frame doesn't know how
to get all of the ia64 registers.
In the current code, the bsp register is calculated based on the cfm and the bsp
values returned from the system. For the innermost frame, the sentinel frame just
goes to the sytem bsp value. The argument registers (32, 33, ...) need to be fetched
from a memory location based on the calculated bsp value. These registers are not accessible
via ptrace. When the sentinel frame is asked to fetch them, it ends up just grabbing
them from the regcache which returns zero.
Are really two values? "bsp" which is the hardware register value you see in the frame; and (for want of a better name) "vbsp", computed from "bsp" and "cfm", which is a per-frame pointer into that the saved register space.
Looking at the existing code, it appears to be:
- fetching `this frame's BSP
- compute the PREV BSP, but then store it in THIS->bsp
so I suspect that the problem is more of the existing frame code being one frame out - it uses the PREV "bsp" when doing stuff for THIS frame.
Can your register unwind code be modified to do things more along those lines? Compute the previous frame's "bsp" but then save it in this_cache?
As for how to "bsp". I see it is done two ways (one for the inner most, and one for other frames) I have a feeling that the uwound "cfm" value may need adjusting. Can it be adjusted so that, for all frames, prev "bsp" can be computed using something like:
this_cache -> prev_bsp
= (frame_unwind_register (next, "bsp")
- frame_unwind_register (next, "cfm").size-of-frame)
instead of occasionally using size-of-locals (but note that I know zilch about how ia64 frames are laid out).
Hmm, I think I missed half your problem:
The argument registers (32, 33, ...) need to be fetched
from a memory location based on the calculated bsp value. These registers are not accessible
via ptrace.
So, once the "vbsp" is computed, gr32-gr127 registers, even for the
inner most frame, get fetched from memory using that "vbsp" value?
Looking at the ia64 code it, unlike the MIPS get_saved_register method,
it doesn't use the next frame, instead using this frame for some of the
register values.
Anyway, the MIPS solved a different problem using the following:
- all the general purpose registers are pseudos
(you'd probably just want the ones causing problems?)
- the pseudo register read/write methods map the pseudos onto raw
registers when at the regcache level
(you'd probably want to map them onto memory locations?)
- the frame unwind code (note the MIPS hasn't switched) does the same
thing for registers saved in a frame - it populates the pseudo register
range of saved addresses with the corresponding register addresses
(very similar - set the saved_regs address for those registers)
- map the debug info register numbers onto the pseudos instead of the
raw registers
(straight forward)
I should note that currently I'm adding code (user-regs) that will let a
target (the MIPS at present) specify registers that are more like what
you have here, this is work-in-progress intended for only the mainline
though.
I have looked into pseudo registers, but this doesn't solve the problem because there isn't
a way AFAICT to notify the frame code to convert a register number into a pseudo register
number. The dwarf2_reg_to_regnum() interface, for example, isn't used by the frame code when
performing an info registers call.
Things like `info registers' use register groups to decide which
registers should be displayed. The default register group
implementation relies on the presence/absence of register names :-/
You might want to customize the register groups (at least for general,
all and float) so that they better identify which registers should be
displayed.
Andrew