From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12409 invoked by alias); 6 Jul 2006 16:47:10 -0000 Received: (qmail 12401 invoked by uid 22791); 6 Jul 2006 16:47:09 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 06 Jul 2006 16:47:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FyX09-0006bG-Lr; Thu, 06 Jul 2006 12:46:53 -0400 Date: Thu, 06 Jul 2006 16:47:00 -0000 From: Daniel Jacobowitz To: Paul Koning Cc: brendan@zen.org, gdb@sources.redhat.com Subject: Re: cont vs run -- the real deal Message-ID: <20060706164653.GA25337@nevyn.them.org> Mail-Followup-To: Paul Koning , brendan@zen.org, gdb@sources.redhat.com References: <44AD3A4E.3020105@zen.org> <17581.15261.101388.267541@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17581.15261.101388.267541@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11+cvs20060403 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-07/txt/msg00015.txt.bz2 On Thu, Jul 06, 2006 at 12:34:37PM -0400, Paul Koning wrote: > >>>>> "Brendan" == Brendan Kehoe writes: > > Brendan> Does there exist in writing an explanation of why "run" > Brendan> works for native programs and "target sim" targets, but > Brendan> "cont" is the correct approach for "target remote ..." ? > Brendan> The docs I'm able to see, and the sources for the various > Brendan> stubs and infcmd.c all seem to leave it implied somehow. > > With remote targets, you're connecting GDB to a program that has > already been started (by some other means, done at the remote end). > So you're gaining control afterwards, which means that you're going to > continue from where it left off. > > The gdbserver case is a bit confusing: when you start an application > via gdbserver, you're getting control on the first instruction. But > it's still "after" the run, though well before main(). Yes, this is a fairly accurate description. This is how I've been thinking about it recently: when you connect to "target child" (native), or "target sim", there's a concept of "nothing is running now, start something". When you connect to "target remote", there isn't such a concept. You're connected to a physical piece of hardware and you're looking at its physical registers; they're always there. I've been sketching a remote protocol extension, like the existing extended-remote target but much more complete, which would allow a remote connection to work along with this model. In that case, you can be connected to a remote target but have nothing running, and even cause the remote stub to attach to something else running on its end of the wire. I'll post more about that in a week or three, once I have a chance to sketch out the usage model a bit better; I've already implemented this but I'm not entirely happy with how, and I have another project to post about first (file transfer is next, I think). -- Daniel Jacobowitz CodeSourcery