From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19459 invoked by alias); 17 Nov 2003 15:39:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19418 invoked from network); 17 Nov 2003 15:39:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Nov 2003 15:39:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ALlTM-00038D-N7; Mon, 17 Nov 2003 10:39:28 -0500 Date: Mon, 17 Nov 2003 15:39:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: "Gdb@Sources.Redhat.Com" Subject: Re: [RFC] upload/download command Message-ID: <20031117153928.GA11964@nevyn.them.org> Mail-Followup-To: Kris Warkentin , "Gdb@Sources.Redhat.Com" References: <03e601c3ad1e$3b2f0ff0$0202040a@catdog> <20031117152619.GA10659@nevyn.them.org> <03fe01c3ad20$64036a50$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03fe01c3ad20$64036a50$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00125.txt.bz2 On Mon, Nov 17, 2003 at 10:35:12AM -0500, Kris Warkentin wrote: > > > I would like to keep these things in our protocol but it might be useful > to > > > generalize the interface out to core gdb. What I'm thinking is that I > > > create a general upload/download command that uses a hook into the > target's > > > code for any special functionality. We could have a general one for > native > > > targets which would basically be 'copy' (probably not all that useful > but > > > there for completeness) and just print 'not implemented' for targets > which > > > don't define the hooks. > > > > Rather don't implement it for native I think... hm, might be easier to > > test the core parts if we did. > > That's what I was thinking....it doesn't really hurt anything. > > > > Any ideas, comments, suggestions, etc.? > > > > For starters, how about describing how it works in your protocol? > > Obviously this could be useful to gdbserver. For mechanics, it may > > want to be another target_read_partial()... > > We actually have a remote_fileopen command in our protocol. The host sends > an open command to the target and then just sends blocks of data for the > target server to write out. Then a close message tells the remote to close > it. It's basically identical to an ordinary open command so you can open on > the remote for reading/writing/etc. Sounds like a good fit for target_read_partial with the exception that we don't have open/close right now. I don't think we'd need to add them for this; for that kind of copy, the remote could assume that it would keep the file open until we'd read the whole file. Might be more efficient not to. > I'm not sure about gdbserver though. Do you even presume the existence of a > filesystem on the remote? Yes. Don't confuse gdbserver with the generic remote protocol; gdbserver is a Unix-equivalent (Linux only right now) stub, using ptrace. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer