[BUG] print_address_numeric

Andrew Cagney ac131313@cygnus.com
Wed Aug 2 04:03:00 GMT 2000


JimB see below.

David Taylor wrote:

>     You forgot the lines:
> 
>       /* Truncate address to the size of a target pointer, avoiding shifts
>          larger or equal than the width of a CORE_ADDR.  The local
>          variable PTR_BIT stops the compiler reporting a shift overflow
>          when it won't occure. */
>       /* NOTE: This assumes that the significant address information is
>          kept in the least significant bits of ADDR - the upper bits were
>          either zero or sign extended.  Should ADDRESS_TO_POINTER() or
>          some ADDRESS_TO_PRINTABLE() be used to do the conversion?  */
> 
>     :-)
> 
> Well, those lines didn't change.

They provided more background.  There is also an entry in the TODO file
if your interested! :-)


> With regard to the question:
> 
>     "Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used
>     to do the conversion?"

Ignore ADDRESS_TO_POINTER().  ADDRESS_TO_PRINTABLE() is the only
applicable value.

> ADDRESS_TO_POINTER -- no; ADDRESS_TO_PRINTABLE -- sure, but I don't need it.


> Currently, TARGET_PTR_BIT says how many bits pointers take in the
> target representation; there is no macro / gdbarch field to say how
> many bits addresses take within CORE_ADDR.
> 
> My proposed TARGET_ADDR_BIT / addr_bit is to add just such a macro /
> field -- with the default value being the value of TARGET_PTR_BIT /
> ptr_bit, so that targets that do nothing will work as they do now.
> 
>     When printing a symbolic address, should it be displayed using GDB's
>     internal format (for MIPS definitly not) or target pointer format.
> 
> Currently, it does neither properly.  It takes the GDB representation,
> and prints the number of bits that are significant on the target.


> And of the two, I feel that it should report an address that the user
> would type in, namely the gdb representation, which would be 0x2000004
> in this case.

The d10v (which has an identical problem) currently does this and it has
proven to be useable.


> I have no objection to having a method (function) *in addition* to the
> macro TARGET_ADDR_BIT.  But, I feel that the macro should be created
> and that print_address_numeric should use it.

The reason for suggesting a method was because it could be used to
implement an arbitrary conversion.  It would be:

	addr & (((LONGEST) 1<<TARGET_ADDR_BIT) - 1)

for your target.  It also restricts this masking operation to just when
an address is printed, internally the full CORE_ADDR is used.

Was there where else you thought you'd need the TARGET_ADDR_BIT macro?


In the end the TARGET_ADDR_BIT vs ADDRESS_TO_PRINTABLE() is fairly
arbitrary - both will do what you need.


JimB, do you have any comments?  This means that GDB has available the
number of significant bits in a CORE_ADDR.


	Andrew

PS: I'm not sure how multi-arching such a macro definition will go.  Try
using TARGET_FLOAT_FORMAT() as an example.


More information about the Gdb-patches mailing list