From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22272 invoked by alias); 7 Sep 2006 22:48:11 -0000 Received: (qmail 22264 invoked by uid 22791); 7 Sep 2006 22:48:10 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Sep 2006 22:48:07 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 71B6726E0B; Thu, 7 Sep 2006 15:48:06 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01999-02-4; Thu, 7 Sep 2006 15:48:04 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id D9BA726E0A; Thu, 7 Sep 2006 15:48:04 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Sep 2006 22:48:04 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 07 Sep 2006 15:47:59 -0700 Subject: RE: Error running remote gdb From: Michael Snyder To: "Bizhan Gholikhamseh (bgholikh)" Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 07 Sep 2006 22:48:00 -0000 Message-Id: <1157669279.9276.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 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: 2006-09/txt/msg00048.txt.bz2 On Wed, 2006-09-06 at 04:47 -0700, Bizhan Gholikhamseh (bgholikh) wrote: > > >The last message from gdb to the target, "$vCont;s:6098;c#67", doesn't > seem to make sense. Personally I don't >understand the semantics of > vCont well enough to say for sure. > > > >Fortunately, vCont can be turned off. ;-) > > > >Can you repeat the experiment approximately like this? > > % gdb test > > (gdb) set debug remote 1 > > (gdb) set remote verbose-resume off > > (gdb) target remote 172.28.176.142:2001 > > (gdb) break main > > (gdb) continue > > (gdb) where > > (gdb) step > > >Send us the result just like before. > > The output was too long to cut and paste so I attached the log file. Bizhan, you're changing too many things between one experiment and the next. This seems to be a completely different program from the last one -- and you seem to have profiling turned on now, which wasn't present last time. OK, well, here are the interesting parts: (gdb) set debug remote 1 (gdb) set remote verbose-resume-packet off (gdb) target remote 172.20.233.74:1234 0x30010390 in ?? () (gdb) break main (gdb) continue Continuing. Sending packet: $M3000ce98,4:7d821008#b1...Ack Packet received: OK Sending packet: $m100413ec,4#be...Ack Packet received: 3860000d Sending packet: $M100413ec,4:7d821008#a6...Ack Packet received: OK Sending packet: $c#63...Ack Set breakpoints at 3000ce98 and 100413ec, and continue. Packet received: T0501:7ffff8e0;40:3000ce98; Sending packet: $m3000ce98,4#c9...Ack Packet received: 7d821008 Sending packet: $M3000ce98,4:9421fff0#15...Ack Packet received: OK Sending packet: $m100413ec,4#be...Ack Packet received: 7d821008 Sending packet: $M100413ec,4:3860000d#9d...Ack Packet received: OK Trap at 3000ce98 -- remove breakpoints. Sending packet: $s#73...Ack Packet received: T0501:7ffff8d0;40:3000ce9c;thread:1e80; Sending packet: $m3000ce98,4#c9...Ack Packet received: 9421fff0 Sending packet: $M3000ce98,4:7d821008#b1...Ack Packet received: OK Sending packet: $m100413ec,4#be...Ack Packet received: 3860000d Sending packet: $M100413ec,4:7d821008#a6...Ack Packet received: OK Sending packet: $Hc0#db...Ack Packet received: E01 Sending packet: $c#63...Ack Packet received: T0501:7ffffe00;40:3000ce98;thread:1e80; Single-step once to get past the breakpoint location. Then re-insert the breakpoints, and continue. Trap again at 3000ce98 -- remove the breakpoints. This repeats a few more times. Finally... Sending packet: $c#63...Ack Packet received: T1b01:7ffffb30;40:30008a08;thread:1e80; Sending packet: $C1b#d6...Ack We received a signal 0x1b (SIGPROF), passed it on to the target, and continued. Packet received: T0501:7ffffe00;40:3000ce98;thread:1e80; Sending packet: $m3000ce98,4#c9...Ack Packet received: 7d821008 Sending packet: $M3000ce98,4:9421fff0#15...Ack Packet received: OK Sending packet: $m100413ec,4#be...Ack Packet received: 7d821008 Sending packet: $M100413ec,4:3860000d#9d...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T1b01:7ffffe00;40:3000ce98;thread:1e80; We remove the breakpoints, single-step, but receive SIGPROF. Sending packet: $S1b#e6...Ack Packet received: T0501:7ffff8c0;40:0fed6adc;thread:1e80; So we singlestep again, passing the SIGPROF on to the target. However, after this singlestep, we seem to land in a random location (0x0fed6adc). Anyway, we re-insert the breakpoints, continue, and *eventually*... Sending packet: $c#63...Ack Packet received: T0501:7ffffdb0;40:100413ec;thread:1e80; [Switching to thread 7808] We arrive at main, remove the breakpoints, and stop. Breakpoint 1, main (argc=1, argv=0x7ffffe44) at main_cma.cpp:13 13 signal(SIGPIPE, SIG_IGN); (gdb) where #0 main (argc=1, argv=0x7ffffe44) at main_cma.cpp:13 (gdb) step And here's the funky part... Sending packet: $m3000ce98,4#c9...Ack Packet received: 9421fff0 Sending packet: $M3000ce98,4:7d821008#b1...Ack Packet received: OK Sending packet: $m100413ec,4#be...Ack Packet received: 3860000d Sending packet: $M100413ec,4:7d821008#a6...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T0501:7ffffdb0;40:100413ec;thread:1e80; At this point, gdb re-inserts the breakpoints, then single-steps. Of course, it immediately encounters the breakpoint at main again. This is incorrect behavior on gdb's part. I don't readily know how to explain it. Let's see... here's your configuration: This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux-gnuspe"... By the way, what does "powerpc-linux-gnuspe"... mean?