From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13942 invoked by alias); 15 Dec 2004 18:34:05 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 13386 invoked from network); 15 Dec 2004 18:33:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Dec 2004 18:33:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iBFIXq13010041 for ; Wed, 15 Dec 2004 13:33:52 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iBFIXqr25250; Wed, 15 Dec 2004 13:33:52 -0500 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iBFIXpbo017820; Wed, 15 Dec 2004 13:33:51 -0500 Subject: Re: Problem with Remote/Serial in Insight From: Keith Seitz To: Bernhard Walle Cc: "insight@sources.redhat.com" In-Reply-To: References: <1102982868.2774.21.camel@lindt.uglyboxes.com> <1103044502.2776.5.camel@lindt.uglyboxes.com> <1103049200.2776.25.camel@lindt.uglyboxes.com> <1103055370.2776.31.camel@lindt.uglyboxes.com> <1103057541.2776.33.camel@lindt.uglyboxes.com> <1103058182.2776.35.camel@lindt.uglyboxes.com> <1103058797.2776.43.camel@lindt.uglyboxes.com> <1103130181.2779.3.camel@lindt.uglyboxes.com> Content-Type: text/plain Message-Id: <1103135630.2779.17.camel@lindt.uglyboxes.com> Mime-Version: 1.0 Date: Wed, 15 Dec 2004 18:34:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q4/txt/msg00148.txt.bz2 On Wed, 2004-12-15 at 10:03, Bernhard Walle wrote: > > Okay, so now what's the next step to start the stub executing? > > Simply for example "break 23" and then "cont". I think that's the > normale way stubs work. Aha! That's what I've been waiting to hear. Yes, that is exactly right: the "normal" process for a stub is to set baud (if using serial), attach, load (optional), and continue -- NOT run. This is why I was so baffled when you said that your target preferences had "attach" and "run" and not "attach" and "continue". In fact, the reason the Target Settings dialog keeps reappearing is because of the "Run" option set in your target settings. From the log you sent me: I global gdbtk_attach_remote Attaching.... I global set_target {CONNECTING TO TARGET: remote /dev/ttyS14 } I global run_executable {Setting new BP at main} I global run_executable {Runnning target...} W global run_executable {msg=Don't know how to run. Try "help target". } I ManagedWin _open {TargetSelection -exportcancel 1 -center -transient} >From this, I conclude that it attached to the target (remote /dev/ttyS14), set a break at main, and attempted to RUN the target (i.e., gdb's "run" command). This elicited an error ('Don't know how to run. Try "help target".'), which caused the target selection dialog to open again. If you are having other problems while specifying "continue", then that's a different problem that we need to address. Keith