Problem converting ia64 to use new frame model

[J. Johnston]

Andrew Cagney wrote:
>> 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 :-/
> 

Thanks, this was just what I was looking for.  I now have info registers
working as it did before the new frame model.

> 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
> 
> 
>