This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] gdb.server testcases (resend)


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 <manjo@austin.ibm.com>:
>
> > 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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]