Problem converting ia64 to use new frame model

[Andrew Cagney]

> 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