From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5143 invoked by alias); 11 Oct 2003 15:40:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5134 invoked from network); 11 Oct 2003 15:40:17 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 11 Oct 2003 15:40:17 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 275882B89; Sat, 11 Oct 2003 11:40:11 -0400 (EDT) Message-ID: <3F88245B.3080504@redhat.com> Date: Sat, 11 Oct 2003 15:40:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raja Saleru Cc: saleru.raja@iap-online.com, gdb@sources.redhat.com Subject: Re: remote serial protocol - gdbserver References: <000001c38eed$89aa2b50$88444e9d@access.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00182.txt.bz2 My wild guess appears to be correct ... > (gdb) l > 53 T_RFLG pk_rflg; > 54 T_RVER pk_rver; > 55 > 56 INT err; > 57 > 58 mmUserPrint(" Enter Root task\n"); > 59 > 60 /* o[WQ?*/ > 61 err = tk_ref_ver( &pk_rver ); > 62 if( err != E_OK) > (gdb) n > Sending packet: $m8c5e83d4,2#03...Ack > Packet received: 04d1 > Sending packet: $M8c5e83d4,2:20c3#15...Ack > Packet received: OK > Sending packet: $s#73...Ack > Packet received: T0510:1e845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:20845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:22845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; I'm guessing that 2874008c is the PC in little-endian byte order. It's just stepped the target into mmUserPrint. > Sending packet: $Hg2#e1...Ack > Packet received: OK > Sending packet: $g#67...Ack > Packet received: > 000000002874008ca866658c00000000b0935e8ca866658c000000000000000000000000 > 00000000000000000000000000000000000000001466658c26845e8c2874008c00000000 > 0000008c0000000000000000000000000000006008000000000000000000000004000000 > 000000002e000000040000000000000000000000487d0000180000001600000004000000 > 040000000c00000039000000080000000300000000000000c81200000000000000000000 > 0000000004000000000000003e000000010000000000000000000000c812000030000000 > 000000000000000001000000000000004c000000 It's pulled the target's registers looking for the "link-register" which should contain the return address. > Sending packet: $m0,2#fb...Ack > ------------------------------------- <1> > Packet received: b0935e8c > Sending packet: $M0,2:20c3#0d...Ack and then sets a breakpoint at that return-address. For some reason GDB think's that's zero (bad packet? bad gdb?). BTW: "b0935e8c" is a bogus return value for "$m0,2,#fb", only two bytes were requested but four were returned, which is wrong (at present). Andrew > ------------------------------------- <2> > Packet received: OK > Sending packet: $c#63...Ack > Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; > > Program received signal SIGTRAP, Trace/breakpoint trap.