Re: RFA: fix GDB casts when pointers are not addresses

Re: RFA: fix GDB casts when pointers are not addresses

[Andrew Cagney]

> - the integer produced is the byte address in the code segment (so for
>   the D10V, this would be the pointer's value times four), or
> 
> - the integer produced is the 16-bit pointer value reinterpreted as a
>   16-bit integer --- no adjustment takes place.
> 
> Currently, GDB implements the former, while GCC implements the former.
> This patch changes GDB to match GCC.


Um, ....

> In the absence of clear direction from an independent standard, I feel
> that GDB should match GCC's behavior.


Can you again provide a concrete example?

Assuming this is accepted, it also needs to be clearly documented.  One 
of the biggest problems is that there is no clear documentation on how 
things should behave.


	Andrew

Re: RFA: fix GDB casts when pointers are not addresses

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Can you again provide a concrete example?

Sure.

$ cat pointer2.c
#include <stdio.h>

main ()
{
  printf ("0x%x\n", (int) &main);
}
$ $CMitsuB/d10v-elf-gcc -g pointer2.c -o pointer2
$ $CMitsuB/d10v-elf-run pointer2
0x5017
$ $DD10v/gdb/gdb pointer2
GNU gdb 2001-07-02-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
(gdb) print (int) &main
$1 = 16476
(gdb) p/x (int) &main
$2 = 0x405c
(gdb) print main
$3 = {int ()} 0x101405c <main>
(gdb) $ 
$ 

> Assuming this is accepted, it also needs to be clearly documented.  One 
> of the biggest problems is that there is no clear documentation on how 
> things should behave.

Sure.  The patch includes a comment which is supposed to set this
straight.  What is it missing?

Re: RFA: fix GDB casts when pointers are not addresses

[Andrew Cagney]

> Sure.
> 
> $ cat pointer2.c
> #include <stdio.h>
> 
> main ()
> {
>   printf ("0x%x\n", (int) &main);
> }
> $ $CMitsuB/d10v-elf-gcc -g pointer2.c -o pointer2
> $ $CMitsuB/d10v-elf-run pointer2
> 0x5017
> $ $DD10v/gdb/gdb pointer2
> GNU gdb 2001-07-02-cvs (MI_OUT)
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
> (gdb) print (int) &main
> $1 = 16476
> (gdb) p/x (int) &main
> $2 = 0x405c


Is this before or after all the changes?  My understanding of what you 
were proposing was that it would output the same as for GCC vis:

$2 = 0x5017

> Sure.  The patch includes a comment which is supposed to set this
> straight.  What is it missing?


I was thinking more of doc/gdb.texinfo.

	Andrew

Re: RFA: fix GDB casts when pointers are not addresses

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > Sure.
> > 
> > $ cat pointer2.c
> > #include <stdio.h>
> > 
> > main ()
> > {
> >   printf ("0x%x\n", (int) &main);
> > }
> > $ $CMitsuB/d10v-elf-gcc -g pointer2.c -o pointer2
> > $ $CMitsuB/d10v-elf-run pointer2
> > 0x5017
> > $ $DD10v/gdb/gdb pointer2
> > GNU gdb 2001-07-02-cvs (MI_OUT)
> > Copyright 2001 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
> > (gdb) print (int) &main
> > $1 = 16476
> > (gdb) p/x (int) &main
> > $2 = 0x405c
> 
> 
> Is this before or after all the changes?  My understanding of what you 
> were proposing was that it would output the same as for GCC vis:
> 
> $2 = 0x5017

The above is the behavior after applying only:
- "RFA: Add builtin void (*) () type"
- "RFA: Revised: Remove D10V-specific code from arch-independent modules"

If I instead apply:
- "RFA: Add builtin void (*) () type"
- "RFA: Revised: Remove D10V-specific code from arch-independent modules"
- "RFA: fix GDB casts when pointers are not addresses"

Then I get this behavior: 

zenia:play$ $DD10v/gdb/gdb pointer2
GNU gdb 2001-07-05-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
(gdb) print (int) &main
$1 = 20503
(gdb) p/x (int) &main
$2 = 0x5017
(gdb) 

Here, the expression yields the same result in GDB as it does under
GCC.

> > Sure.  The patch includes a comment which is supposed to set this
> > straight.  What is it missing?
> 
> I was thinking more of doc/gdb.texinfo.

Something like this?

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.38
diff -c -c -b -F'^(' -r1.38 gdb.texinfo
*** gdb.texinfo	2001/04/02 08:58:19	1.38
--- gdb.texinfo	2001/07/05 23:23:31
***************
*** 4381,4387 ****
  
  Casts are supported in all languages, not just in C, because it is so
  useful to cast a number into a pointer in order to examine a structure
! at that address in memory.
  @c FIXME: casts supported---Mod2 true?
  
  @value{GDBN} supports these operators, in addition to those common
--- 4381,4388 ----
  
  Casts are supported in all languages, not just in C, because it is so
  useful to cast a number into a pointer in order to examine a structure
! at that address in memory.  Where the value of a cast is undefined by
! the language, GDB tries to interpret the cast the same way GCC would.
  @c FIXME: casts supported---Mod2 true?
  
  @value{GDBN} supports these operators, in addition to those common

Re: RFA: fix GDB casts when pointers are not addresses

[Andrew Cagney]

> Then I get this behavior: 
> 
> zenia:play$ $DD10v/gdb/gdb pointer2
> GNU gdb 2001-07-05-cvs (MI_OUT)
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
> (gdb) print (int) &main
> $1 = 20503
> (gdb) p/x (int) &main
> $2 = 0x5017
> (gdb) 
> 
> Here, the expression yields the same result in GDB as it does under
> GCC.


Phew!

This only leaves ``x/...''.  How does that behavour compare?  The most 
important thing was that given:

(gdb) print main
$1 = {int ()} 0x101405c <main>
(gdb) print/x &main

things like:

(gdb) x/i main
disassembled <main>
(gdb) x/i 0x101405c
disassembled <main>
(gdb) x/b 0x101405c
hex dump of main

and

(gdb) disassemble main
disassembled <main>
(gdb) disassemble 0x101405c

continued to work (assuming that they did before :-/).  Similar for data 
values.

	Andrew

(Yes I'm trying to build a gcc for the d10v)

Re: RFA: fix GDB casts when pointers are not addresses

[Andrew Cagney]

> - the integer produced is the byte address in the code segment (so for
>   the D10V, this would be the pointer's value times four), or
> 
> - the integer produced is the 16-bit pointer value reinterpreted as a
>   16-bit integer --- no adjustment takes place.
> 
> Currently, GDB implements the former, while GCC implements the former.
> This patch changes GDB to match GCC.
> 
> 
> Um, ....

Jim,  I take it you ment:

GDB implements the former, while GCC implements the latter.

	Andrew

Re: RFA: fix GDB casts when pointers are not addresses

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> This only leaves ``x/...''.  How does that behavour compare?

Yes, the commands you gave above still work; see below.  There are no
new regressions on the test suite, other than those I mentioned in my
original I-hate-the-D10V patch, so I assume the data commands still
work, too.

Michael Snyder asked privately about whether assigning values to $pc
still worked (he's thinking of a bug someone reported internal to Red
Hat).  The transcript below shows that that still works, too.


> The most 
> important thing was that given:
> 
> (gdb) print main
> $1 = {int ()} 0x101405c <main>
> (gdb) print/x &main
> 
> things like:
> 
> (gdb) x/i main
> disassembled <main>
> (gdb) x/i 0x101405c
> disassembled <main>
> (gdb) x/b 0x101405c
> hex dump of main
> 
> and
> 
> (gdb) disassemble main
> disassembled <main>
> (gdb) disassemble 0x101405c
> 
> continued to work (assuming that they did before :-/).  Similar for data 
> values.

Here's the demo:

$ $DD10v/gdb/gdb pointer
GNU gdb 2001-07-06-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=d10v-elf"...
(gdb) x/3i main
0x101405c <main>:       st      r11, @-sp       ->      st      r13, @-sp
0x1014060 <main+4>:     mv      r11, sp ||      nop
0x1014064 <main+8>:     ldi.l   r0, 0x4

(These are the correct instructions, according to objdump -d.)

(gdb) x/3i 0x101405c
0x101405c <main>:       st      r11, @-sp       ->      st      r13, @-sp
0x1014060 <main+4>:     mv      r11, sp ||      nop
0x1014064 <main+8>:     ldi.l   r0, 0x4
(gdb) x/4b 0x101405c
0x101405c <main>:       0x76    0xbf    0xed    0xbf

(Those are the correct bytes, according to objdump -d.)

(gdb) disassemble main
Dump of assembler code for function main:
0x101405c <main>:       st      r11, @-sp       ->      st      r13, @-sp
0x1014060 <main+4>:     mv      r11, sp ||      nop
0x1014064 <main+8>:     ldi.l   r0, 0x4
0x1014068 <main+12>:    ldi.s   r1, 0x2 ||      nop
0x101406c <main+16>:    bl.l    0x1014130 <printf>
0x1014070 <main+20>:    ldi.l   r0, 0x1c
0x1014074 <main+24>:    ldi.s   r1, 0x2 ||      nop
0x1014078 <main+28>:    bl.l    0x1014130 <printf>
0x101407c <main+32>:    ldi.l   r0, 0x39
0x1014080 <main+36>:    ldi.l   r1, 0x5017
0x1014084 <main+40>:    bl.l    0x1014130 <printf>
0x1014088 <main+44>:    add3    sp, r11, 0x0
0x101408c <main+48>:    ld      r13, @sp+       ->      ld      r11, @sp+
0x1014090 <main+52>:    jmp     r13     ||      nop
End of assembler dump.
(gdb) disassemble 0x101405c
Dump of assembler code for function main:
0x101405c <main>:       st      r11, @-sp       ->      st      r13, @-sp
0x1014060 <main+4>:     mv      r11, sp ||      nop
0x1014064 <main+8>:     ldi.l   r0, 0x4
0x1014068 <main+12>:    ldi.s   r1, 0x2 ||      nop
0x101406c <main+16>:    bl.l    0x1014130 <printf>
0x1014070 <main+20>:    ldi.l   r0, 0x1c
0x1014074 <main+24>:    ldi.s   r1, 0x2 ||      nop
0x1014078 <main+28>:    bl.l    0x1014130 <printf>
0x101407c <main+32>:    ldi.l   r0, 0x39
0x1014080 <main+36>:    ldi.l   r1, 0x5017
0x1014084 <main+40>:    bl.l    0x1014130 <printf>
0x1014088 <main+44>:    add3    sp, r11, 0x0
0x101408c <main+48>:    ld      r13, @sp+       ->      ld      r11, @sp+
0x1014090 <main+52>:    jmp     r13     ||      nop
End of assembler dump.
(gdb) break main
Breakpoint 1 at 0x1014064: file pointer.c, line 10.
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .rodata, size 0x26a lma 0x2000004
Loading section .data, size 0x3cc lma 0x2000270
Loading section .text, size 0x8990 lma 0x1014000
Start address 0x1014000
Transfer rate: 294448 bits in <1 sec.
(gdb) run
Starting program: /home/jimb/d10v/play/pointer 

Breakpoint 1, main () at pointer.c:10
10        EXPR (sizeof (void *));
(gdb) p/x $pc
$1 = 0x1014064
(gdb) x/3i $pc
0x1014064 <main+8>:     ldi.l   r0, 0x4
0x1014068 <main+12>:    ldi.s   r1, 0x2 ||      nop
0x101406c <main+16>:    bl.l    0x1014130 <printf>
(gdb) set $pc = 0x1014070
(gdb) p/x $pc
$2 = 0x1014070
(gdb) 

Re: RFA: fix GDB casts when pointers are not addresses

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> This only leaves ``x/...''.  How does that behavour compare?
> 
> 
> Yes, the commands you gave above still work; see below.  There are no
> new regressions on the test suite, other than those I mentioned in my
> original I-hate-the-D10V patch, so I assume the data commands still
> work, too.
> 
> Michael Snyder asked privately about whether assigning values to $pc
> still worked (he's thinking of a bug someone reported internal to Red
> Hat).  The transcript below shows that that still works, too.


Ok, thanks.
	Andrew

Re: RFA: fix GDB casts when pointers are not addresses

[David Taylor]

    From: Jim Blandy <jimb@zwingli.cygnus.com>
    Date: Thu, 28 Jun 2001 17:57:04 -0500 (EST)

    This patch changes GDB to match GCC's behavior when casting pointers
    to integers on machines where pointers are not direct byte addresses
    (like Harvard architectures).

    This patch is a prerequisite for removing the D10V-specific code from
    the GDB core (for example, see value_at in valops.c).

    The details:

    In the scope of a declaration like this:

	    void (*f) ();

    the C standards say expressions like these yield unspecified values:

	    (int) f;

    In the absence of clear direction from an independent standard, I feel
    that GDB should match GCC's behavior.

    On most processors, there's a single obvious behavior for a cast from
    a pointer to an integer of the same size.  However, the D10V has a
    256k code address space, indexed by 16-bit pointers; all instructions
    are 32-bit values, naturally aligned, so we multiply a 16-bit code
    pointer's value by four to get the corresponding byte address in code
    space.  This means that there are two plausible interpretations for a
    cast from code ptr to integer:

    - the integer produced is the byte address in the code segment (so for
      the D10V, this would be the pointer's value times four), or

    - the integer produced is the 16-bit pointer value reinterpreted as a
      16-bit integer --- no adjustment takes place.

    Currently, GDB implements the former, while GCC implements the former.
    This patch changes GDB to match GCC.

former, former; one should be latter...

    One could argue that `value_as_long' should not convert pointers to
    addresses, but there are many other places in GDB that assume it will.

    2001-06-28  Jim Blandy  <jimb@redhat.com>

	    * valops.c (value_cast): When casting a pointer to an integer,
	    don't convert it to an address.

I approve of bringing the compiler and debugger into agreement on how
to interpret an expression.  You might want to make note of that in
the ChangeLog entry.

Approved.