From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney 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: <3B43E232.1040104@cygnus.com> References: X-SW-Source: 2001-07/msg00072.html 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 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: 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 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: 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 To: Jim Blandy 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. > >