This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [13/15] Address printing


Pierre Muller wrote:

>   it seems to me that
>   paddress has a noticeably different behavior from
>   removed paddr function:
>   
>   paddr was always of the size of 2*ptr_size
> and had no leading '0x' while paddress
> doesn't have a fixed length and has a leading '0x'.
> 
>   I was wondering if there are no testsuite failures
> related to that change.

For paddr_nz, most users already manually prepended
the '0x'.  My patch removed those while changing the
paddr_nz to paddress, thus keeping the output unchanged.

For those uses of paddr where it seemed the exact format
(padded with leading zeros, no 0x) was crucial, e.g. when
used as part of a remote / monitor protocol, I've replaced
the paddr with phex, again leaving the output unchanged.

There were some uses of paddr_nz where the missing 0x
was clearly a bug; likewise, there were some uses of
paddr to display addresses to users where there seemed
no reason to use anything but the default address printing
format.  In those cases, I've changed the code to use
paddress instead, changing the user-visisble output.

This caused exactly one testsuite failure, which I fixed
by adapting the test case (part of the patch).


>   core_addr_to_string seems also not to display 
> addresses with the size of the current target:
> it uses sizeof (CORE_ADDR) which might be different
> from the size of the current target especially for
> --enable-targets=all.
> 
>   I saw that you used phex (addr, addr_size)
> at several places, wouldn't be better to
> use target_gdbarch pointer size if target_gdbarch 
> is valid and fall back to sizeof (CORE_ADDR) only
> if current target is not set or if the pointer size 
> is not set?

core_addr_to_string is not supposed to have anything to
do with the target format.  The sole purpose of this
routine is to dump a CORE_ADDR into a string in some
internal unique format (that is never supposed to be
shown to the user, except possibly as internal debug
output); the only requirement is that the original
CORE_ADDR value (no matter what target) can be recovered
via string_to_core_addr.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]