This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Torubles with remote stub for m68k
On Mon, Jun 24, 2002 at 05:56:48PM -0400, Peter Barada wrote:
>
> >>> When I execute that with gdb-5.1.1, it attempts to step the processor
> >>> without removing the trap instruction so the target processor never
> >>> steps past the trap instruction.
> >>
> >>You also should try with 5.2 or CVS rather than 5.1.1, probably...
> >
> >I'm grabbing and building it now. I'll post an update tomorrow.
> >
>
> I got to it quicker than I thought. Nope, same problem as with gdb-5.1.1:
>
> [Switching to thread 1 (Thread 9)]#0 FRSfindfont (
> name=0x1fd6b70 "AlbertusMT", idptr=0x1fd6b4c, ftype=0x1fd6b50,
> fclass=0x1fd6b54, font_mat=0x4c589c, painttype=0x1fd6b58,
> fontname=0x1fd6b5c) at ../pdi/fntsockt.c:604
> 604 if (fs_first_unused == (FRS_ID *) NULL)
> (gdb) show version
> GNU gdb 5.2
> Copyright 2002 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=m68k-elf".
> (gdb) set debug remote 1
> (gdb) si
> Sending packet: $Hc9#e4...Ack
> Packet received: OK
> Sending packet: $s#73...Ack
> Packet received: T05thread:9;
> Sending packet: $g#67...Ack
> Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6ab04084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000
> 604 if (fs_first_unused == (FRS_ID *) NULL)
> (gdb) p/x $pc
> $1 = 0x3af3c
> (gdb) si
> Sending packet: $s#73...Ack
> Packet received: T05thread:9;
> Sending packet: $g#67...Ack
> Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6aac4084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000
> 604 if (fs_first_unused == (FRS_ID *) NULL)
> (gdb) p/x $pc
> $2 = 0x3af3c
> (gdb)
>
> With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's
> responsibility to save/restore the brekpoint across a 's' packet, or
> is that the stub's responsibility?
>
> Any help is appreciated!
If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then
it is the client's responsibility to clear it. It would be nice to
know why that isn't happening. To observe it in action you can use
gdbserver on a GNU/Linux system...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer