register_type method

[Andrew Cagney]

> 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.
> 
> 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.
> 
> Once I get that merge done, I can rework the ptr and address convertions to
> be a bit more sane.

If I understand right, the 4 byte PC is due to an historic decision 
related to the remote protocol (dates back to before pointer to address).

Try making the "pc" a 2 byte pseudo register that that the architecture 
pseudo read/write methods map onto a corresponding raw register.

Andrew