Re: (patch) hpjyg23: gdbtypes.[ch] & values.c

[Jimmy Guo <guo at cup dot hp dot com>]

>> + #ifdef BFD64
>> +   builtin_type_CORE_ADDR = builtin_type_unsigned_long_long;
>> + #else
>> +   builtin_type_CORE_ADDR = builtin_type_unsigned_long;
>> + #endif
>
>Can you expand a little - looks like there isn't a builtin_type_* for
>pointer :-(  That makes makes the introduction of a builtin_type for
>target pointers a pretty good idea.

builtin_type_CORE_ADDR is used in cp-valprint.c and valops.c in offset
calculation to skip over entries of pointer type.

>BFD64:  I'm not sure this is the right test. Should some characteristic
>of the ABFD be tested instead?

Suggestion for a better alternative is appreciated.

>I suspect that builtin_type_uint{32,64} would be safer.  There are
>machines with 64 bit longs :-)

Oh yes, sure builtin_type_uint{32,64} would probably be safer.

>***************
>*** 955,964 ****
>           * the beginning of the vtable; but first we have to adjust
>           * by HP_ACC_VFUNC_START to account for other entries */
>  
>!         /* pai: FIXME: 32x64 problem here, a word may be 8 bytes in
>!          * which case the multiplier should be 8 and values should be
>long */
>!         vp = value_at (builtin_type_int,
>!                        coreptr + 4 * (TYPE_FN_FIELD_VOFFSET (f, j) +
>HP_ACC_VFUNC_START), NULL);
>  
>          coreptr = *(CORE_ADDR *) (VALUE_CONTENTS (vp));
>          /* coreptr now contains the address of the virtual function */
>--- 954,965 ----
>           * the beginning of the vtable; but first we have to adjust
>           * by HP_ACC_VFUNC_START to account for other entries */
>  
>!         vp = value_at (builtin_type_CORE_ADDR,
>!                        coreptr +
>!                        sizeof (CORE_ADDR) *
>!                        (TYPE_FN_FIELD_VOFFSET (f, j) +
>!                         HP_ACC_VFUNC_START),
>!                        NULL);
>  
>          coreptr = *(CORE_ADDR *) (VALUE_CONTENTS (vp));
>          /* coreptr now contains the address of the virtual function */
>
>FYI, you can't trust sizeof (CORE_ADDR).  CORE_ADDR is a type that is
>large enough to fit a target pointer.  Often it is larger.  Generally
>code uses TARGET_PTR_BIT (?), with builtin_type_CORE_ADDR perhaphs an
>attribute of that can be used.

Sure.

If possible, can you make the changes accordingly?  I can fix all other
uses in the patches to come as well.

- Jimmy Guo