[BUG] print_address_numeric

[Andrew Cagney]

David Taylor wrote:

> Right.  And if TARGET_PTR_BIT was 16 bits instead of 32, then the
> calculated length should be 2 bytes rather than 4 and it shouldn't
> need to be special cased...  at least, that is the theory.

:-)



> Hmmm, looking at them again, I think you're right; but I think that
> the variable 'addr' is playing a dual role -- it's both an address and
> a pointer.

> it's an address.  So, a POINTER_TO_ADDRESS probably needs to be thrown
> in there.

Yes.  Probably wait until the problem has been proven.

>     TARGET_ADDR_BIT - it needs to (post) initializing it with somthing from
>     the architecture vector.  I've never tried it ...
> 
> Making the change and regenerating gdbarch.[ch], the function
> verify_gdbarch now has the lines:
> 
>   if ((GDB_MULTI_ARCH >= 1)
>       && (gdbarch->ptr_bit == 0))
>     internal_error ("gdbarch: verify_gdbarch: ptr_bit invalid");
>   if (gdbarch->addr_bit == 0)
>     gdbarch->addr_bit = gdbarch->ptr_bit;
> 

> + v:1:TARGET_ADDR_BIT:int:addr_bit::::8 * sizeof (void*):0:gdbarch->ptr_bit

Check gdbarch.h for the non- multi-arch case.  I suspect
``gdbarch->ptr_bit'' will need to be TARGET_PTR_BIT which is why I'm not
100% sure on it working.

The hack:

/* NOTE/WARNING: The parameter is called ``current_gdbarch'' so that it
   just happens to match the global variable ``current_gdbarch''.  That
   way macros refering to that variable get the local and not the global
   version - ulgh.  Once everything is parameterised with gdbarch, this
   will go away. */

I used on gdbarch_dump() may need to be re-used.

	Andrew