[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