From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12139 invoked by alias); 29 Feb 2008 22:09:56 -0000 Received: (qmail 12096 invoked by uid 22791); 29 Feb 2008 22:09:55 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Feb 2008 22:09:38 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 5D2AA3C556; Fri, 29 Feb 2008 14:09:36 -0800 (PST) Subject: Re: target remote-attach? From: Michael Snyder To: Paul Koning Cc: gdb@sourceware.org In-Reply-To: <18376.27047.383933.915287@gargle.gargle.HOWL> References: <1204316091.19253.525.camel@localhost.localdomain> <18376.27047.383933.915287@gargle.gargle.HOWL> Content-Type: text/plain Date: Fri, 29 Feb 2008 22:20:00 -0000 Message-Id: <1204322975.19253.529.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00272.txt.bz2 On Fri, 2008-02-29 at 15:23 -0500, Paul Koning wrote: > >>>>> "Michael" == Michael Snyder writes: > > Michael> Just thinking aloud... we ought to have a sort of > Michael> "remote-attach" command, that would allow us to connect to a > Michael> remote target when it is already in a "run" state. Right > Michael> now the initial handshake protocol prevents doing that. > > Michael> The target might be waiting to tell gdb "I stopped because > Michael> of a SIGTRAP", or similar, or it might actually be running, > Michael> and need to be stopped via a serial BRK or the like. After > Michael> that, we would be in a sane state from which we could do the > Michael> usual remote_open handshake. > > Michael> Or is there something like that already? > > I haven't seen the problem you mention. gdbserver allows attaching to > a running process (by PID) and that has always worked for me. For > that matter, it works also with a native gdb (local debug). > > Similarly, I've used the remote target protocol for kernel debug, > connecting after the kernel panic handler has invoked the stub via a > breakpoint instruction. That too works fine. Yeah, the situation I have in mind is, say you've already been connected, and you've said "continue", and then while gdb was waiting for the target to say "OK, I've stopped", you lost the connection. The situation you mention (native "attach") is kind of analogous. You want to connect to a running target, possibly interrupt it, (native attach sends the child a signal), and then handshake.