register_type method

register_type method

[Theodore A. Roth]

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:


static struct type *
avr_register_type (struct gdbarch *gdbarch, int reg_nr)
{
  if (reg_nr == AVR_PC_REGNUM)
/*     return builtin_type_void_func_ptr; */
/*     return builtin_type_uint32; */
    return builtin_type_CORE_ADDR;
  if (reg_nr == AVR_SP_REGNUM)
    return builtin_type_void_data_ptr;
  else
    return builtin_type_uint8;
}


Ted Roth

Re: register_type method

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: register_type method

[Theodore A. Roth]

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.

Ted Roth

Re: register_type method

[Daniel Jacobowitz]

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

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