Re: [BUG] print_address_numeric

[Andrew Cagney <ac131313 at cygnus dot com>]

David Taylor wrote:

>     The d10v (which has an identical problem) currently does this and it has
>     proven to be useable.
> 
> Does it print the right value?  Or does the user just cope with it?

The d10v had TARGET_PTR_BIT == 4 bytes so it avoids the problem you
encountered.  This is why, in various places you see the code:

	if (D10V and pointer)
	  len = 2;

> I don't have a d10v build sitting around, but I would expect the that
> on the d10v, if I set a breakpoint at address 0x2000004, it would
> print it as 4 rather than 0x2000004 or 1.  I was thinking that both
> the processor I'm working on and the d10v would set TARGET_ADDR_BIT to
> 32 and TARGET_PTR_BIT to 16.

It should but it didn't.  It has all those other D10V_* macros instead.

>     Was there where else you thought you'd need the TARGET_ADDR_BIT macro?
> 
> Hmmm, I hadn't specifically checked.  It looks like...
> 
> TARGET_PTR_BIT ==> TARGET_ADDR_BIT:
>     2 places in read_var_value (findvar.c)

I don't think these need changing.  They are reading target pointers and
not target h/w addresses?
Hmm, actually I'm not sure.  Is your definition of TARGET_ADDR_BIT the
number of significant bits in a CORE_ADDR needed to represent the target
address space or the actual address size of the target?


>     1 place in build_gdbtypes (gdbtypes.c)
builtin_type_CORE_ADDR? Yes (it isn't actually used though).

> I suspect that with the addition of the TARGET_ADDR_BIT macro and the
> proper changes of TARGET_PTR_BIT vs TARGET_ADDR_BIT and extract_* /
> store_* vs POINTER_TO_ADDRESS / ADDRESS_TO_POINTER that many uses of
> GDB_TARGET_IS_D10V could be eliminated.

> Are you unsure how multi-arching TARGET_ADDR_BIT would go?  Or
> unsure about how multi-arching ADDRESS_TO_PRINTABLE would go?

TARGET_ADDR_BIT - it needs to (post) initializing it with somthing from
the architecture vector.  I've never tried it ...