From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16737 invoked by alias); 19 May 2005 16:53:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15674 invoked from network); 19 May 2005 16:52:32 -0000 Received: from unknown (HELO e35.co.us.ibm.com) (32.97.110.133) by sourceware.org with SMTP; 19 May 2005 16:52:32 -0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JGqULK493730 for ; Thu, 19 May 2005 12:52:30 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JGqUcs255202 for ; Thu, 19 May 2005 10:52:30 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JGqUm0002421 for ; Thu, 19 May 2005 10:52:30 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JGqUSx002410 for ; Thu, 19 May 2005 10:52:30 -0600 Received: from lazy.austin.ibm.com (lazy.austin.ibm.com [9.53.94.97]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id j4JGqTdr090688 for ; Thu, 19 May 2005 11:52:29 -0500 Date: Thu, 19 May 2005 17:52:00 -0000 From: Manoj Iyer X-X-Sender: manjo@lazy To: gdb-patches@sources.redhat.com Subject: Re: [RFC] gdb.server testcases (resend) In-Reply-To: <1116490026.428c492a8f3d8@imap.linux.ibm.com> Message-ID: References: <1116490026.428c492a8f3d8@imap.linux.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg00475.txt.bz2 Daniel, Are you commiting your gdbserver patch? seems like that patch fixes atleast 64bit debugger with 64bit debuggee. ----- manjo +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Cogito ergo sum + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Thu, 19 May 2005, Wu Zhou wrote: > Quoting Manoj Iyer : > > > On the host side > > ---------------- > > ./gdbserver 9.3.190.182:1234 /tmp/test > > Process /tmp/test created; pid = 8323 > > Stop pc is 0x40010470 > > Listening on port 1234 > > Remote debugging from host 9.3.190.187 > > readchar: Got EOF > > Remote side has terminated connection. GDBserver will reopen the > > connection. > > Listening on port 1234 > > > > It seems that file /tmp/test is a 32-bits binary. I also tried 64-bits > gdbsrever against 64-bits binary, it worked somewhat better, but failed > at another place. Below I will summarize my test results, wishing that > it might be helpful to you. > > 1. 32-bits gdbserver with 32-bits debuggee > on my power4 box, I can get a 32-bits gdbserver without "-m64" option. > My test shows that it works well with 32-bits debuggee. > > 2. 64-bits gdbserver with 32-bits debuggee > > without Daniel's patch, the 64-bits gdbserver on my power4 box also > report "reading register I/O error" at register 1. After applying > Daniel's patch, gdbserver could start the 32-bits debuggee and begin > to wait for the remote gdb's connection. > > On the host side, my gdb session is somewhat the same as yours. It > seems that gdb at the host side expects 32-bits register, something > like: > > T0501:ffffe6b0;40:40010470; > > but the remote gdbserver sends back 64-bits value: > > T0501:00000000ffffe6b0;40:0000000040010470; > > So it report "Remote register badly formatted" error. > > 3. 64-bits gdbserver with 64-bits debuggee > > With the patched 64-bits gdbserver. I could go some further with the > 64-bits debuggee. The target side gdbserver session is like this: > > # ./gdbserver :2345 ../testsuite/gdb.base/break > Process ../testsuite/gdb.base/break created; pid = 17669 > Stop pc is 0x80000053e0 > Listening on port 2345 > Remote debugging from host 127.0.0.1 > Stop pc is 0x8000013040 > Stop pc is 0x8000013040 > Stop pc is 0x80000075ec > Stop pc is 0x8000013040 > Stop pc is 0x8000013040 > Stop pc is 0x8000012a20 > Stop pc is 0x8000013040 > Stop pc is 0x8000013040 > Stop pc is 0x8000012aac > Stop pc is 0x100006a8 > Stop pc is 0x100006a8 > ... > > The host side gdb session is like this: > > # ./gdb/gdb -q > (gdb) file ./gdb/testsuite/gdb.base/break > Reading symbols from ./gdb/testsuite/gdb.base/break...done. > Using host libthread_db library "/lib64/tls/libthread_db.so.1". > (gdb) target remote localhost:2345 > Remote debugging using localhost:2345 > 0x00000080000053e0 in ?? () > (gdb) bt > #0 0x00000080000053e0 in ?? () > #1 0x0000000000000000 in ?? () > (gdb) b 94 > Breakpoint 1 at 0x100006a8: file ../../gdb/testsuite/gdb.base/break.c, line 94. > (gdb) c > Continuing. > > Breakpoint 1, main (argc=1, argv=0x1fffffff328, envp=0x1fffffff338) at ../../gdb/testsuite/gdb.base/break.c:94 > 94 printf ("%d\n", factorial (atoi ("6"))); /* set breakpoint 1 here */ > (gdb) s > factorial (value=6) at ../../gdb/testsuite/gdb.base/break.c:111 > 111 if (value > 1) { /* set breakpoint 7 here */ > (gdb) s > 114 return (value); /* set breakpoint 19 here */ > (gdb) n > > Program received signal SIGFPE, Arithmetic exception. > 0x000000800013fd64 in .vfprintf () from /lib64/tls/libc.so.6 > (gdb) > > > > On remote side > > -------------- > > ./gdb > > GNU gdb 6.3.50.20050516-cvs > > Copyright 2004 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 "powerpc64-unknown-linux-gnu". > > Setting up the environment for debugging gdb. > > No symbol table is loaded. Use the "file" command. > > No symbol table is loaded. Use the "file" command. > > .gdbinit:8: Error in sourced command file: > > No breakpoint number 0. > > (gdb) file /tmp/test > > Reading symbols from /tmp/test...done. > > Using host libthread_db library "/lib64/tls/libthread_db.so.1". > > (gdb) target remote 9.3.190.182:1234 > > Remote debugging using 9.3.190.182:1234 > > Remote register badly formatted: > > T0501:00000000ffffe6b0;40:0000000040010470; > > here: fffe6b0;40:0000000040010470; > > (gdb) > > > > > > > > ----- > > manjo > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > + Cogito ergo sum + > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > On Wed, 18 May 2005, Daniel Jacobowitz wrote: > > > > > On Wed, May 18, 2005 at 10:37:56AM -0500, Manoj Iyer wrote: > > > > > > > > Daniel, > > > > > > > > The patches did not apply cleanly to mainline, so I had to hand patch the > > > > files. Also, in the final link stage for gdbserver ld complained that: > > > > > > > > /usr/bin/ld: warning: powerpc:common64 architecture of input file > > > > `inferiors.o' is incompatible with powerpc:common output > > > > > > > > so I had to add a -m64 to the linker call. > > > > > > > > gdbserver still broken:. > > > > > > > > $ ./gdbserver uranus.ltc.austin.ibm.com /tmp/server > > > > Process /tmp/server created; pid = 4747 > > > > reading register 70: Input/output error > > > > Exiting > > > > > > My reading of the kernel source suggests that FPSCR should be accessible > > > using that address. You should figure out why it isn't. > > > > > > At a guess your headers are broken: > > > /* NOTE: cagney/2005-02-08: On some 64-bit GNU/Linux systems the > > > kernel headers incorrectly contained the 32-bit definition of > > > PT_FPSCR. For the 32-bit definition, floating-point > > > registers occupy two 32-bit "slots", and the FPSCR lives in > > > the secondhalf of such a slot-pair (hence +1). For 64-bit, > > > the FPSCR instead occupies the full 64-bit 2-word-slot and > > > hence no adjustment is necessary. Hack around this. */ > > > > > > -- > > > Daniel Jacobowitz > > > CodeSourcery, LLC > > > > > > > > > > Cheers > - Wu Zhou >