RFA: addresses and pointers may be different sizes while printing

RFA: addresses and pointers may be different sizes while printing

[Jim Blandy]

This is a preparatory patch for removing the D10V dependencies that
have crept into the core of GDB (for example: value_at in valops.c).

The D10V uses 16-bit pointers to index 256k code space.  Since all
D10V instructions are 32 bits long, and naturally aligned, the PC is
really 18 bits long, and the bottom two bits are always zero.  Within
GDB, we model this by using 32-bit *addresses*, and converting
*pointers* (which are 16 bits long) to *addresses* at the appropriate
points.

Without this conversion (which is necessary for some other
architectures as well), the alternative is for GDB to think that
pointers are 32 bits long, while the program being debugged thinks
they're 16 bits long.  As you'd expect, chaos results.

In any case, print_scalar_formatted assumes that pointers and the
addresses they represent are the same length.  This isn't true for the
D10V, so we need to remove that assumption.  That's what this patch is
supposed to do.

There are probably similar problems elsewhere, but we can fix them as
we find them.  I found this one, so I'm fixing it.

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

	* printcmd.c (print_scalar_formatted): If we are printing an
	address, remember that TARGET_ADDR_BIT is not always equal to
	TARGET_PTR_BIT.

Index: gdb/printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.21
diff -c -r1.21 printcmd.c
*** gdb/printcmd.c	2001/06/11 16:05:24	1.21
--- gdb/printcmd.c	2001/06/28 22:25:00
***************
*** 390,395 ****
--- 390,401 ----
    else if (format != 'f')
      val_long = unpack_long (type, valaddr);
  
+   /* If the value is a pointer, and pointers and addresses are not the
+      same, then at this point, the value's length is TARGET_ADDR_BIT, not
+      TYPE_LENGTH (type).  */
+   if (TYPE_CODE (type) == TYPE_CODE_PTR)
+     len = TARGET_ADDR_BIT;
+ 
    /* If we are printing it as unsigned, truncate it in case it is actually
       a negative signed value (e.g. "print/u (short)-1" should print 65535
       (if shorts are 16 bits) instead of 4294967295).  */
 

Re: RFA: addresses and pointers may be different sizes while printing

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Would you have an example illustrating the actual affect of this change?

Sure.  First, read the section ``Pointers Are Not Always Addresses''
in doc/gdbint.texinfo.  It actually uses the D10V as its running
example.

This patch only affects architectures where code addresses and
pointers are different sizes, like the D10V.  Without my larger D10V
patch ("RFA: Remove D10V-specific code from arch-independent
modules"), GDB represents all code pointers as 32 bit values, so this
patch has no effect there, either.

However, the fact that GDB believes pointers are 32 bits long, while
the target believes they are 16 bits long, is exactly the source of
all the GDB_TARGET_IS_D10V stuff and D10V-specific macros.  The whole
idea is to get rid of them.

So, assume that we've first applied my patch referenced above.  Now
sizeof (void (*)()) == 2, as it should.  When we print the address of
a function, we have some troubles:

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

main ()
{
  printf ("Hello, world!\n");
}
$ $CMitsuB/d10v-elf-gcc -g hello.c -o hello
$ $DD10v/gdb/gdb hello
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 main
$1 = {int ()} 0x101405c <main>
(gdb) print/x &main
$2 = 0x405c
(gdb) 

Notice that print/x yields only the bottom 16 bits of the address of
main.

Some further explanation is in order here: on the D10V, our toolchain
treats the data and code address spaces (64k and 256k in size) as
subregions of a single, larger 32-bit address code space.  Code space
starts at 0x01000000.  So main is 0x1405c bytes from the base of code
space.

So when we're printing out that code address, not only are we
stripping off the top 0x01 byte, but we're also stripping off the
second-to-top byte (also 0x01), which carries vital information.
0x0100405c is a completely distinct, perfectly valid code address.

Those bits are tossed by the following code in print_scalar_formatted:

  /* If we are printing it as unsigned, truncate it in case it is actually
     a negative signed value (e.g. "print/u (short)-1" should print 65535
     (if shorts are 16 bits) instead of 4294967295).  */
  if (format != 'd')
    {
      if (len < sizeof (LONGEST))
	val_long &= ((LONGEST) 1 << HOST_CHAR_BIT * len) - 1;
    }

At this point, `len' is correctly set to the size of the type in bits:
16.  However, since we've already converted the 16-bit code pointer
into a 32-bit code address (which is what the user wants to see), this
code masks off bits which actually matter.

My change adds code which says, in effect, "If we are printing an
address, use a `len' of TARGET_ADDR_BIT, not TARGET_PTR_BIT."  I'm
assuming that TARGET_ADDR_BIT should be 32 for an architecture like
the D10V.

With my patch, GDB behaves like this:

$ $DD10v/gdb/gdb hello
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 main
$1 = {int ()} 0x101405c <main>
(gdb) print/x &main
$2 = 0x101405c
(gdb) 

Note that the upper sixteen bits of $2 haven't been masked off: the
address prints correctly with and without the /x format.

Re: RFA: addresses and pointers may be different sizes while printing

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> Would you have an example illustrating the actual affect of this change?
> 
> 
> Sure.  First, read the section ``Pointers Are Not Always Addresses''
> in doc/gdbint.texinfo.  It actually uses the D10V as its running
> example.


gdb.texinfo?  Do we need a gdb.base/harvard.exp?


> This patch only affects architectures where code addresses and
> pointers are different sizes, like the D10V.  Without my larger D10V
> patch ("RFA: Remove D10V-specific code from arch-independent
> modules"), GDB represents all code pointers as 32 bit values, so this
> patch has no effect there, either.


I can imagine that.  I was kind of assuming you're examples would be 
pre/post all changes.


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


then


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


to be 110% sure, all of:

	(gdb) print main
	(gdb) print &main
	(gdb) print/x main
	(gdb) print/x &main

end up displaying the same hex (CORE_ADDR) value?

	Andrew

Re: RFA: addresses and pointers may be different sizes while printing

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> to be 110% sure, all of:
> 
> 	(gdb) print main
> 	(gdb) print &main
> 	(gdb) print/x main
> 	(gdb) print/x &main
> 
> end up displaying the same hex (CORE_ADDR) value?

Yes, except for the third one, which says 

(gdb) print/x main
$3 = Value can't be converted to integer.

Re: RFA: addresses and pointers may be different sizes while printing

[Andrew Cagney]

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


I think that is still too vague and fuzzy.  There needs to be a concrete 
example and a testcase.

These are probably something to do separate to these patches but they do 
need doing.  At present, there is nothing explaining (and testing) GDB's 
behavour on a harvard architecture.

	Andrew

Re: RFA: addresses and pointers may be different sizes while printing

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> I think that is still too vague and fuzzy.  There needs to be a concrete 
> example and a testcase.
> 
> These are probably something to do separate to these patches but they do 
> need doing.  At present, there is nothing explaining (and testing) GDB's 
> behavour on a harvard architecture.

Oh, I got confused.  What I posted there was a rationale for my change
to value_cast, which (I think) is more than adequately documented with
the patch above.  What you want is an explanation of our whole
philosophy regarding pointers, addresses, separate address spaces, and
so on.

I'll chew on it.  Perhaps now's the time to restart the discussion of
Harvard Architecture machines, put together a coherent picture of how
things are supposed to behave, and document it.

In the meantime, can my change go in?  :)

Re: RFA: addresses and pointers may be different sizes while printing

[Andrew Cagney]

> These are probably something to do separate to these patches but they do 
>> need doing.  At present, there is nothing explaining (and testing) GDB's 
>> behavour on a harvard architecture.
> 
> 
> Oh, I got confused.  What I posted there was a rationale for my change
> to value_cast, which (I think) is more than adequately documented with
> the patch above.  What you want is an explanation of our whole
> philosophy regarding pointers, addresses, separate address spaces, and
> so on.
> 
> I'll chew on it.  Perhaps now's the time to restart the discussion of
> Harvard Architecture machines, put together a coherent picture of how
> things are supposed to behave, and document it.


While you're chewing away (:-) could you file a CR anyway?  That way 
this thread has ``closure''.

	Andrew

Re: RFA: addresses and pointers may be different sizes while printing

[David Taylor]

    From: Jim Blandy <jimb@zwingli.cygnus.com>
    To: gdb-patches@sources.redhat.com
    Date: Thu, 28 Jun 2001 17:35:46 -0500 (EST)

    This is a preparatory patch for removing the D10V dependencies that
    have crept into the core of GDB (for example: value_at in valops.c).

    The D10V uses 16-bit pointers to index 256k code space.  Since all
    D10V instructions are 32 bits long, and naturally aligned, the PC is
    really 18 bits long, and the bottom two bits are always zero.  Within
    GDB, we model this by using 32-bit *addresses*, and converting
    *pointers* (which are 16 bits long) to *addresses* at the appropriate
    points.

    Without this conversion (which is necessary for some other
    architectures as well), the alternative is for GDB to think that
    pointers are 32 bits long, while the program being debugged thinks
    they're 16 bits long.  As you'd expect, chaos results.

    In any case, print_scalar_formatted assumes that pointers and the
    addresses they represent are the same length.  This isn't true for the
    D10V, so we need to remove that assumption.  That's what this patch is
    supposed to do.

    There are probably similar problems elsewhere, but we can fix them as
    we find them.  I found this one, so I'm fixing it.

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

	    * printcmd.c (print_scalar_formatted): If we are printing an
	    address, remember that TARGET_ADDR_BIT is not always equal to
	    TARGET_PTR_BIT.

Approved.