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: register_type method


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


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