From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16376 invoked by alias); 3 Jan 2002 22:20:37 -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 16249 invoked from network); 3 Jan 2002 22:20:34 -0000 X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Thu, 03 Jan 2002 14:20:00 -0000 From: Keith Seitz X-X-Sender: To: "Martin M. Hunt" cc: Insight Mailing List Subject: Re: [RFA] Run button - second try In-Reply-To: <200201032200.OAA08617@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-q1/txt/msg00015.txt.bz2 On Thu, 3 Jan 2002, Martin M. Hunt wrote: > Some people (like me) do both native and remote debugging. If you attempt > to do so, you cannot just hit the RUN button and expect the right thing to happen. > This is because the run_load, run_attach, run_run, and run_cont preferences are > changed. To make things work, I had to make them session-dependent. Rather than > make lots of changes all over the place, I just modified session.tcl to load > the old preferences variables as new sessions are loaded. Ok, I understand part of this, but I'm afraid I just don't understand one last bit. See below. > I also fixed the run button so that if you click it while a program is being debugged, > you get a dialog that allows you to restart your debug session or cancel. (Maybe this answers my questions about what's going on? See below.) > Also, it can take a long time to connect to a remote target, especially if > it isn't responding, so change the RUN botton to the STOP sign so the > user can cancel the connect. If the user does cancel, the target dialog pops > up again. This isn't guaranteed to work, though, is it? I can imagine that it will do a no-op for anything that doesn't connect via serial or tcp. (Do we have many such targets? Do we care?) Ok, here's the part I don't get (patch below). Here's my reading of the code: When Run is pressed and we must attach to the target, if we successfully re-attach to the target we were originally debugging, a dialog comes up asking if we want to switch to a different target. This doesn't sound right. Why would I ever want to do that 99% of the time? For the remaining one percent of the time, I can always go to File->Target Settings to change. I don't know. This sounds fishy. Can you explain a little more? Hmm. Wait a second. Based on your comment above ("I also fixed the run button..."), I think that what you mean here is for the dialog to offer the option of selecting a new target before re-running the current debug executable. Is this right? If so, I would really, really prefer that the dialog message be made more like: "A program is already running.\nAre you sure you want to re-run it?" Then there could be an option to click on which says something like "select different target". Then "Yes" or "No" buttons. When "Yes" is pressed, the program will re-run. If the "select different target" option was set, we would first bring up the TargetDialog. Am I any closer to understanding? Keith > @@ -1146,10 +1148,29 @@ proc run_executable { {auto_start 1} } { > > # Attach > if {$gdb_target_name == "" || [pref get gdb/src/run_attach]} { > - if {[gdbtk_attach_remote] == "ATTACH_CANCELED"} { > + set r [gdbtk_attach_remote] > + if { $r == "ATTACH_CANCELED" || $r == "ATTACH_ERROR"} { > + return > + } > + > + # > + if {$r == "ATTACH_TARGET_UNCHANGED"} { > + set msg "A program is being debugged already.\n" > + append msg "Do you want to select another target?" > + if {[gdbtk_tcl_query $msg no]} { > + # YES > + set ::gdb_target_name "" > + set ::gdb_target_cmd "" > + set r [gdbtk_attach_remote] > + if { $r == "ATTACH_CANCELED" ||$r == "ATTACH_ERROR"} { > return > } > + } else { > + # NO > + return > + } > } > + } > > # Download > if {[pref get gdb/src/run_load] && $gdb_target_name != "exec"} {