Consistent format for memory addresses

Consistent format for memory addresses

[Nick Roberts]

At one stage, the GDB command "disassemble" output seven hex digits for memory
addresses on 32 bit Intel (GNU/Linux):

(gdb) disassemble main     
Dump of assembler code for function main:
0x80484c6 <main>:       push   %ebp
0x80484c7 <main+1>:     mov    %esp,%ebp
0x80484c9 <main+3>:     sub    $0x238,%esp
0x80484cf <main+9>:     and    $0xfffffff0,%esp
0x80484d2 <main+12>:    mov    $0x0,%eax
0x80484d9 <main+19>:    movl   $0x0,0xffffff98(%ebp)
^^^^^^^^^

Now there are eight:

(gdb) disassemble main     
Dump of assembler code for function main:
0x080484c6 <main+0>:    push   %ebp
0x080484c7 <main+1>:    mov    %esp,%ebp
0x080484c9 <main+3>:    sub    $0x238,%esp
0x080484cf <main+9>:    and    $0xfffffff0,%esp
0x080484d2 <main+12>:   mov    $0x0,%eax
0x080484d7 <main+17>:   sub    %eax,%esp
0x080484d9 <main+19>:   movl   $0x0,0xffffff98(%ebp)
^^^^^^^^^^
Thats fine, eight sits better in the binary world and it makes it
consistent with the output of "info break"

(gdb) break main
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x080484d9 in main at myprog.c:55
                            ^^^^^^^^^^
However "info frame" gives:

(gdb) info frame
Stack level 0, frame at 0xbffff730:
 eip = 0x80484d9 in main (myprog.c:55); saved eip 0x4006015a
       ^^^^^^^^^

Still seven digits. The human mind adjusts easily to such differences, but
front ends---or at least the one I'm writing for Emacs---don't.

So that I don't have to keep making piecemeal changes, I suggest that
memory addresses in "info frame" has the same format as disassemble
and "info break". I've not looked at the internals but maybe they could
all be printed with the same procedure call.

WDYT?

Nick

Re: Consistent format for memory addresses

[Daniel Jacobowitz]

On Wed, May 25, 2005 at 03:18:42PM +1200, Nick Roberts wrote:
> However "info frame" gives:
> 
> (gdb) info frame
> Stack level 0, frame at 0xbffff730:
>  eip = 0x80484d9 in main (myprog.c:55); saved eip 0x4006015a
>        ^^^^^^^^^
> 
> Still seven digits. The human mind adjusts easily to such differences, but
> front ends---or at least the one I'm writing for Emacs---don't.

I have no objection - but is it really that hard to treat it as a
number?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Consistent format for memory addresses

[Nick Roberts]

 > > However "info frame" gives:
 > > 
 > > (gdb) info frame
 > > Stack level 0, frame at 0xbffff730:
 > >  eip = 0x80484d9 in main (myprog.c:55); saved eip 0x4006015a
 > >        ^^^^^^^^^
 > > 
 > > Still seven digits. The human mind adjusts easily to such differences, but
 > > front ends---or at least the one I'm writing for Emacs---don't.
 > 
 > I have no objection - but is it really that hard to treat it as a
 > number?

In truth I don't mind seven or eight digits. What makes it difficult for me
is if the output of the CLI commands constantly change. I know the answer is
GDB/MI but I'm (still!) hoping to get one release of Emacs out using
annotations.

I don't know the logic behind the change in disassemble but my concern is that
it will mean that others like "info frame" will change at some unspecified
time in the future. I realise that I have to expect CLI output to move
forward, I'm just trying to ensure it happens in a co-ordinated manner.

Nick

Re: Consistent format for memory addresses

[Nick Roberts]

 > I have no objection - but is it really that hard to treat it as a
 > number?

I see what you're saying now. I take the current address from "info frame" and
then search for it in the output of disassemble.  This lets me place an arrow
on the appropriate line in the "disassembly window". That means I have to
treat the address as a string which presents a problem when the different
commands use different formats.

Nick

Re: Consistent format for memory addresses

[M.M. Kettenis]

Nick Roberts <nickrob@snap.net.nz> wrote:

> (gdb) info frame
> Stack level 0, frame at 0xbffff730:
>  eip = 0x80484d9 in main (myprog.c:55); saved eip 0x4006015a
>        ^^^^^^^^^
>
> Still seven digits. The human mind adjusts easily to such differences, but
> front ends---or at least the one I'm writing for Emacs---don't.
>
> So that I don't have to keep making piecemeal changes, I suggest that
> memory addresses in "info frame" has the same format as disassemble
> and "info break". I've not looked at the internals but maybe they could
> all be printed with the same procedure call.
>
> WDYT?

I'm all for consistency.  But I think you should realize that pointers
can be 64-bit too, or even 48-bit, so your code beter not depend on a
fixed number of digits.

Cheers,

Mark

Re: Consistent format for memory addresses

[Nick Roberts]

 > I'm all for consistency.  But I think you should realize that pointers
 > can be 64-bit too, or even 48-bit, so your code beter not depend on a
 > fixed number of digits.

I've only got a 32 bit machine and AFAIK the output format of CLI commands
isn't precisely documented (why should it be, its for users, not frontends).
The disassembly view is only one part of the frontend and, I will have to rely
on bug reports to cover other architectures.  For the moment, I'm just aiming
at damage limitation.

Nick

Re: Consistent format for memory addresses

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 25 May 2005 15:52:47 +1200
> Cc: gdb@sources.redhat.com
> 
> In truth I don't mind seven or eight digits. What makes it difficult for me
> is if the output of the CLI commands constantly change.

But this (and similar) changes should not be very hard to accommodate
for in Emacs, even if you search for the address as a string.  For
instance, you could use a regexp that allows for an arbitrary number
of leading zeroes, right?

Or am I missing something?

Re: Consistent format for memory addresses

[Nick Roberts]

Eli Zaretskii writes:
 > > From: Nick Roberts <nickrob@snap.net.nz>
 > > Date: Wed, 25 May 2005 15:52:47 +1200
 > > Cc: gdb@sources.redhat.com
 > > 
 > > In truth I don't mind seven or eight digits. What makes it difficult for me
 > > is if the output of the CLI commands constantly change.
 > 
 > But this (and similar) changes should not be very hard to accommodate
 > for in Emacs, even if you search for the address as a string.  For
 > instance, you could use a regexp that allows for an arbitrary number
 > of leading zeroes, right?
 > 
 > Or am I missing something?

Sure all differences can be accommodated if I know what the rules are. But as
Mark pointed out there are different systems. Presumably they might have
different rules. However, if the same function is used to print out all the
addresses, I don't need to know what format the address has. Since the output
address the two commands would be identical, I can simply record it from one
command and look for it in the other.

The discrepancy in the example I referred to arises because disassemble now
uses ui_out_field_core_addr while "info frame" still uses
deprecated_print_address_numeric. The deprecated prefix suggests that this
arrangement is not permanent. I would like to make changes now like the one
below. Clearly it would be sensible to change the other calls to
deprecated_print_address_numeric and, as it stands, it probably introduces a
memory leak and it might conflict with MI. However, I would like some
re-assurance that such a change would be accepted before going to the trouble
of providing a proper patch.

Nick


*** /home/nick/src/gdb/stack.c.~1.132.~	2005-05-18 20:17:24.000000000 +1200
--- /home/nick/src/gdb/stack.c	2005-05-26 09:09:17.000000000 +1200
***************
*** 958,964 ****
        printf_filtered (":\n");
      }
    printf_filtered (" %s = ", pc_regname);
!   deprecated_print_address_numeric (get_frame_pc (fi), 1, gdb_stdout);
  
    wrap_here ("   ");
    if (funname)
--- 958,964 ----
        printf_filtered (":\n");
      }
    printf_filtered (" %s = ", pc_regname);
!   ui_out_field_core_addr (uiout, "addr", get_frame_pc (fi));
  
    wrap_here ("   ");
    if (funname)

Re: Consistent format for memory addresses

[Daniel Jacobowitz]

On Thu, May 26, 2005 at 09:11:09AM +1200, Nick Roberts wrote:
> Eli Zaretskii writes:
>  > > From: Nick Roberts <nickrob@snap.net.nz>
>  > > Date: Wed, 25 May 2005 15:52:47 +1200
>  > > Cc: gdb@sources.redhat.com
>  > > 
>  > > In truth I don't mind seven or eight digits. What makes it difficult for me
>  > > is if the output of the CLI commands constantly change.
>  > 
>  > But this (and similar) changes should not be very hard to accommodate
>  > for in Emacs, even if you search for the address as a string.  For
>  > instance, you could use a regexp that allows for an arbitrary number
>  > of leading zeroes, right?
>  > 
>  > Or am I missing something?
> 
> Sure all differences can be accommodated if I know what the rules are. But as
> Mark pointed out there are different systems. Presumably they might have
> different rules. However, if the same function is used to print out all the
> addresses, I don't need to know what format the address has. Since the output
> address the two commands would be identical, I can simply record it from one
> command and look for it in the other.

You know it's a number - it's going to stay a number.  A function to
turn one hex number into a regular expression that would match it with
leading zeros wouldn't be much work.

> The discrepancy in the example I referred to arises because disassemble now
> uses ui_out_field_core_addr while "info frame" still uses
> deprecated_print_address_numeric. The deprecated prefix suggests that this
> arrangement is not permanent. I would like to make changes now like the one
> below. Clearly it would be sensible to change the other calls to
> deprecated_print_address_numeric and, as it stands, it probably introduces a
> memory leak and it might conflict with MI. However, I would like some
> re-assurance that such a change would be accepted before going to the trouble
> of providing a proper patch.

The change is not correct.  The ui_out_* output is considerably different in MI
mode.  I think paddr_nz will do what you want though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Consistent format for memory addresses

[Nick Roberts]

 > You know it's a number - it's going to stay a number.  A function to
 > turn one hex number into a regular expression that would match it with
 > leading zeros wouldn't be much work.

If you are saying that the address formats will only differ in their number of
leading zeros, and not in other ways, then that is good enough for my purposes.

Nick

Re: Consistent format for memory addresses

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 26 May 2005 11:08:19 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> 
>  > You know it's a number - it's going to stay a number.  A function to
>  > turn one hex number into a regular expression that would match it with
>  > leading zeros wouldn't be much work.
> 
> If you are saying that the address formats will only differ in their number of
> leading zeros, and not in other ways, then that is good enough for my purposes.

Well, it's a number, right?  What else can possibly change in the
address format that leaves the numeric value unmodified?  The only
other thing, besides leading zeros, that I can think of is sign
extension in some weird 32/64 bit situations.  But that's a theory, I
don't even know if it's possible in practice.  So I'd say leading
zeros is all you need to worry about for now.

Re: Consistent format for memory addresses

[Daniel Jacobowitz]

On Thu, May 26, 2005 at 06:39:51AM +0300, Eli Zaretskii wrote:
> Well, it's a number, right?  What else can possibly change in the
> address format that leaves the numeric value unmodified?  The only
> other thing, besides leading zeros, that I can think of is sign
> extension in some weird 32/64 bit situations.  But that's a theory, I
> don't even know if it's possible in practice.  So I'd say leading
> zeros is all you need to worry about for now.

For the record it is possible in practice - this happens a lot on GDB
for MIPS.  However GDB should generally be consistent in this case
about whether the leading bits are displayed, and in _that_ case,
inconsistency is usually a bug.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Consistent format for memory addresses

[Nick Roberts]

 > > If you are saying that the address formats will only differ in their
 > > number of leading zeros, and not in other ways, then that is good enough
 > > for my purposes.
 >
 >
 > Well, it's a number, right?  What else can possibly change in the
 > address format that leaves the numeric value unmodified?  The only
 > other thing, besides leading zeros, that I can think of is sign
 > extension in some weird 32/64 bit situations.  But that's a theory, I
 > don't even know if it's possible in practice.  So I'd say leading
 > zeros is all you need to worry about for now.

If you're not constrained by knowledge of the internals of GDB like myself,
there are many possibilities. One command could start with a different
offset. It could work in the other direction.  From the start or end of the
heap, the stack. It could be in octal, in decimal...

...but as you say, thats not the case.

Nick