Re: register_type method

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jun 14, 2003 at 05:00:11PM -0700, Theodore A. Roth wrote:
> On Sat, 14 Jun 2003, Daniel Jacobowitz wrote:
> 
> :)On Sat, Jun 14, 2003 at 03:27:00PM -0700, Theodore A. Roth wrote:
> :)> Hi,
> :)> 
> :)> What builtin type should the *_register_type method return for the PC?
> :)> 
> :)> I would think that it it should be builtin_type_void_func_ptr like the d10v
> :)> does, but when I use that for the avr, I only get 2 bytes for the PC
> :)> register size and I need 4 bytes. Using builtin_type_uint32 works but just
> :)> doesn't feel right.
> :)> 
> :)> I also tried using builtin_type_CORE_ADDR and that seemed to work as well as
> :)> builtin_type_uint32.
> :)> 
> :)> Here's my avr_register_type method I'm currently playing with:
> :)
> :)I've only been mostly-following previous discussions of the AVR, but -
> :)why do you need a different number of bytes for a void (*)() than you
> :)do for the PC?  It seems to me that the PC should always be converted
> :)(is this still POINTER_TO_ADDRESS?) in the same way a void (*)() would
> :)be.
> 
> That's a good question. I'm not sure I have an answer which is probably the 
> root of my confusion. I think you are correct that convertion should be the 
> same. I just did some comparison of the d10v and avr *_make_?addr() and 
> *_convert_?addr_to_raw() functions and it looks like the avr might not be 
> using those to the extent that it should not to mention a few 
> inconsistencies I just noticed. :-( 
> 
> Our remote targets (a simulator and a jtag ice glue program) try to do the
> word address to byte address translation before replying to gdb queries. I'm
> beginning to wonder if that was a mistake since we then have some
> translations done on the gdb side and some on the remote target side.  Thus
> making things much more complicated than they need to be.
> 
> Looks like I need to give this more thought and rework it a bit.

Fortunately, you can correct this in GDB.  You could make PC_REGNUM a
pseudo, backed by the raw register holding what you got from the
target, and use that to undo the shifting.

> In the mean time, is there any objections to me finishing up the merging of
> my frame-ify and removal of deprecated interface changes? I have those
> working now and they work better than what is currently in cvs.

Certainly no objection.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer