From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25618 invoked by alias); 23 Nov 2005 02:52:40 -0000 Received: (qmail 25610 invoked by uid 22791); 23 Nov 2005 02:52:40 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw2a.lmco.com (HELO mailgw2a.lmco.com) (192.91.147.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 02:52:36 +0000 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id jAN2qWle001909; Tue, 22 Nov 2005 21:52:32 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IQD00301ZZKN5@lmco.com>; Tue, 22 Nov 2005 18:52:32 -0800 (PST) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IQD00HRZZZJYD@lmco.com>; Tue, 22 Nov 2005 18:52:31 -0800 (PST) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Nov 2005 18:52:31 -0800 Date: Wed, 23 Nov 2005 03:09:00 -0000 From: "Newman, Sarah R" Subject: RE: single stepping mips remote programs built with gcc 4.0 To: Jim Blandy Cc: Daniel Jacobowitz , gdb@sources.redhat.com Message-id: <5990BE666D0436419054489CDD9D505409EE88F9@emss01m10.us.lmco.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00516.txt.bz2 > You've talked about GDB inserting breakpoints for software > single-stepping, but you're not using software single-stepping here. > Those memory writes are for your user breakpoints at the entry point > and exit point of main. The 's' packet indicates that the stub itself > is doing the single-stepping. Which run? The first run I had a user breakpoint at the very beginning of main, the second run I had the breakpoint one instruction after the beginning. Run 1: Num Type Disp Enb Address What 1 breakpoint keep y 0xffffffff80001998 in main at tmp.c:11 2 breakpoint keep y 0xffffffff800019b0 in main at tmp.c:14 gdb) step (gdb) p/x $pc $2 = 0x800019a0 (gdb) set debug remote 1 (gdb) step Sending packet: $m80001998,4#70...Ack Packet received: 27bdffe8 Sending packet: $M80001998,4:0005000d#43...Ack <-- user breakpoint Packet received: OK Sending packet: $m800019b0,4#91...Ack Packet received: 03e00008 Sending packet: $M800019b0,4:0005000d#64...Ack <-- user breakpoint Packet received: OK Sending packet: $s#73...Ack Packet received: S05 Sending packet: $p25#d7...Ack Packet received: 800019a4 Sending packet: $s#73...Ack Packet received: S05 Sending packet: $p25#d7...Ack Packet received: 80001990 Sending packet: $p1d#05...Ack Packet received: 8402ba60 Sending packet: $p1f#07...Ack Packet received: 800019a8 Sending packet: $m8000199c,4#9b...Ack Packet received: afbf0010 Sending packet: $m800019a0,4#90...Ack Packet received: 0c000664 Sending packet: $m800019a4,4#94...Ack Packet received: 00000000 Sending packet: $c#63...Ack ---- Run 2: Num Type Disp Enb Address What 2 breakpoint keep y 0xffffffff800019b0 in main at tmp.c:14 3 breakpoint keep y 0xffffffff8000199c in main at tmp.c:11 <-- one instruction later than run 1 Sending packet: $m800019b0,4#91...Ack Packet received: 03e00008 Sending packet: $M800019b0,4:0005000d#64...Ack <-- user breakpoint Packet received: OK Sending packet: $m8000199c,4#9b...Ack Packet received: afbf0010 Sending packet: $M8000199c,4:0005000d#6e...Ack <-- user breakpoint Packet received: OK Sending packet: $Hc0#db...Ack Packet received: ENN Sending packet: $s#73...Ack Packet received: S05 Sending packet: $p25#d7...Ack Packet received: 800019a4 Sending packet: $s#73...Ack Packet received: S05 Sending packet: $p25#d7...Ack Packet received: 80001990 Sending packet: $p1d#05...Ack Packet received: 8402ba60 Sending packet: $p1f#07...Ack Packet received: 800019a8 Sending packet: $m80001998,4#70...Ack Packet received: 27bdffe8 Sending packet: $m800019a0,4#90...Ack Packet received: 0c000664 Sending packet: $m800019a4,4#94...Ack Packet received: 00000000 Sending packet: $m80001998,4#70...Ack Packet received: 27bdffe8 Sending packet: $M80001998,4:0005000d#43...Ack <-- not user breakpoint Packet received: OK Sending packet: $c#63...Ack Packet received: S02 Sending packet: $p25#d7...Ack Packet received: 800019b0 > > > Sending packet: $m8000199c,4#9b...Ack > > Packet received: afbf0010 > > Sending packet: $m800019a0,4#90...Ack > > Packet received: 0c000664 > > Sending packet: $m800019a4,4#94...Ack > > Packet received: 00000000 > > This is weird. It looks like GDB is doing some prologue analysis > here, but it's not starting at any function's entry point. That, > combined with the fact that you said that disassembly shows you the > wrong code, makes me wonder if the debug info is right. > > When you say 'print &a' or 'print &main', do you get the > right addresses? Yes, I get the right addresses. When I disassemble the functions in the console I get the right thing too. But when I use insight to show an assembly listing of a particular function, it shows the function after. I did not realize that disassembling in the console and showing the assembly of a function with insight could give different results. I said something inaccurate before -- I was compiling this program with "-gstabs+" , not "-g". I have seen different behavior depending on if I use "-g" or "-gstabs+" with some other programs, but I just tried both flags and it doesn't seem to make a difference here.