Re: [BUG] print_address_numeric

[David Taylor <taylor at cygnus dot com>]

    Date: Wed, 02 Aug 2000 21:03:26 +1000
    From: Andrew Cagney <ac131313@cygnus.com>

    JimB see below.

    David Taylor wrote:

    > Well, those lines didn't change.

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

Yep, I should have provided more context so that people had a better
idea what was being discussed.  Yes, I'm 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.

Agreed.

    > 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.

Does it print the right value?  Or does the user just cope with it?

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.

I believe that for the d10v, if we set TARGET_ADDR_BIT to 32 and set
TARGET_PTR_BIT to 16, then with the proper change of some instances of
TARGET_PTR_BIT to TARGET_ADDR_BIT and the judicious replacement of
some store_* and extract_* function calls with calls to, respectively,
ADDRESS_TO_POINTER and POINTER_TO_ADDRESS, then most (all?)  instances
of GDB_TARGET_IS_D10V could be eliminated.

    > 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?

Hmmm, I hadn't specifically checked.  It looks like...

TARGET_PTR_BIT ==> TARGET_ADDR_BIT:
    2 places in read_var_value (findvar.c)
    1 place in build_gdbtypes (gdbtypes.c)

extract_* ==> POINTER_TO_ADDRESS
    1 place in sigtramp_saved_pc (blockframe.c, leave TARGET_PTR_BIT's alone)
    1 place in find_addr_symbol (symtab.c, leave TARGET_PTR_BIT alone)
	[we probably don't care about this one -- it's "#if 0"'ed.]

Undoubtably others as well -- I just found those with a quick grep on
TARGET_PTR_BIT.

Some of the places where GDB_TARGET_IS_D10V is used, there's code
like:

  len = TYPE_LENGTH (type);

  /* Pointers on D10V are really only 16 bits, 
     but we lie to gdb elsewhere... */
  if (GDB_TARGET_IS_D10V && TYPE_CODE (type) == TYPE_CODE_PTR)
    len = 2;

(the above fragment is from value_from_register in findvar.c).

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.

I'm not sufficiently familiar with the d10v nor with the places where
the GDB_TARGET_IS_D10V macro is used to be certain of it, though.

    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.

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