From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8100 invoked by alias); 29 Feb 2008 20:23:30 -0000 Received: (qmail 8080 invoked by uid 22791); 29 Feb 2008 20:23:29 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkps320.us.dell.com (HELO aussmtpmrkps320.us.dell.com) (143.166.224.254) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Feb 2008 20:23:09 +0000 X-IronPort-AV: E=Sophos;i="4.25,429,1199685600"; d="scan'208";a="346057189" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 29 Feb 2008 14:23:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18376.27047.383933.915287@gargle.gargle.HOWL> Date: Fri, 29 Feb 2008 20:26:00 -0000 From: Paul Koning To: msnyder@specifix.com Cc: gdb@sourceware.org Subject: Re: target remote-attach? References: <1204316091.19253.525.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid 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/msg00267.txt.bz2 >>>>> "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. paul