From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15426 invoked by alias); 17 Nov 2003 15:34:13 -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 15410 invoked from network); 17 Nov 2003 15:34:11 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 17 Nov 2003 15:34:11 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id KAA05662; Mon, 17 Nov 2003 10:48:30 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA25595; Mon, 17 Nov 2003 10:34:08 -0500 Message-ID: <03fe01c3ad20$64036a50$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" , "Gdb@Sources.Redhat.Com" References: <03e601c3ad1e$3b2f0ff0$0202040a@catdog> <20031117152619.GA10659@nevyn.them.org> Subject: Re: [RFC] upload/download command Date: Mon, 17 Nov 2003 15:34:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-11/txt/msg00124.txt.bz2 > > 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. I'm not sure about gdbserver though. Do you even presume the existence of a filesystem on the remote? cheers, Kris