Re: New gdb 31 & 64 bit patches for S/390

Andrew Cagney
2001-07-04T21:02:00Z

Attached are comments on s390-nat.c. There were very few problems here!

Andrew
From ac131313@cygnus.com Wed Jul 04 21:02:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: DJBARROW@de.ibm.com
Cc: gdb-patches@sourceware.cygnus.com, s390-patches@gnu.org, schwidefsky@de.ibm.com, ARENZ@de.ibm.com
Subject: Re: New gdb 31 & 64 bit patches for S/390
Date: Wed, 04 Jul 2001 21:02:00 -0000
Message-id: <3B43E021.1020502@cygnus.com>
References: <C1256A00.006F3FCE.00@d12mta09.de.ibm.com>
X-SW-Source: 2001-07/msg00074.html
Content-length: 330

The attached are comments on tm-s390.h. As far as I can tell the file
could be empty. This is pretty significant since it means that you've
managed to pure-multi-arch the s390 target. Congratulations!

To summarise the comments, my main concern is that it appeared to
contain many s390-nat.c specific declarations.

Andrew
From ac131313@cygnus.com Wed Jul 04 21:04:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: DJBARROW@de.ibm.com
Cc: gdb-patches@sourceware.cygnus.com, s390-patches@gnu.org, schwidefsky@de.ibm.com, ARENZ@de.ibm.com
Subject: Re: New gdb 31 & 64 bit patches for S/390
Date: Wed, 04 Jul 2001 21:04:00 -0000
Message-id: <3B43E31F.3020302@cygnus.com>
References: <C1256A00.006F3FCE.00@d12mta09.de.ibm.com>
X-SW-Source: 2001-07/msg00076.html
Content-length: 71

Attached are comments on nm-linux.h. Basicly it is approved.

Andrew
From ac131313@cygnus.com Wed Jul 04 22:14:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: addresses and pointers may be different sizes while printing
Date: Wed, 04 Jul 2001 22:14:00 -0000
Message-id: <3B43F682.1040502@cygnus.com>
References: <20010628223546.BDE7F5E9CB@zwingli.cygnus.com>
X-SW-Source: 2001-07/msg00077.html
Content-length: 1221

Jim,

Would you have an example illustrating the actual affect of this change?

Andrew

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