This is the mail archive of the gdb@sources.redhat.com 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: Problem converting ia64 to use new frame model


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.



I had thought about that myself, but I can understand what the original writer was thinking. The bsp register value of the innermost frame has to be modified to get the bsp address of where the innermost input argument registers are located. To an end-user, it is more useful to know the bsp area for the current frame is rather than being forced to do the calculation manually which involves bit shifting and differs depending on whether you are an innermost frame or not. So the bsp the user's currently see is essentially a pseudo-register.

The bsp issue still doesn't help with regards to r32-r39.  These registers contain input
arguments to the function and are certainly useful to see.  I have made some
progress recently using pseudo-registers.  I have the innermost frame correctly printing
out the arguments and I can backtrace reasonably well   However, info registers on the innermost
frame still shows the argument registers as 0.  This is because I used a mapping of registers
to pseudo-registers and this mapping never gets done for the info registers case.  I am
currently using the set_gdbarch_dwarf2_reg_to_regnum interface.  Is there is a better way
to do this mapping?

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


I am sort of doing that now. I just don't call it prev_bsp because it is actually used to find the input registers for the current frame. Another calculation is required to find the bsp that holds the registers for the previous frame.

Andrew






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