From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6827 invoked by alias); 15 Oct 2003 23:12:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6814 invoked from network); 15 Oct 2003 23:12:45 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Oct 2003 23:12:45 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1A9uou-0008CJ-M8 for ; Wed, 15 Oct 2003 19:12:44 -0400 Date: Wed, 15 Oct 2003 23:12:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] target read/write partial Message-ID: <20031015231244.GA30203@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3F8DC73C.4090205@redhat.com> <20031015223255.GA17644@nevyn.them.org> <3F8DD39C.4090007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8DD39C.4090007@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00527.txt.bz2 On Wed, Oct 15, 2003 at 07:09:16PM -0400, Andrew Cagney wrote: > >On Wed, Oct 15, 2003 at 06:16:28PM -0400, Andrew Cagney wrote: > > > >>Hello, > >> > >>This patch adds target read/write partial methods. > >> > >>It's almost ready for prime time. I want to first see through some > >>other target cleanups namely: > >>+ /* FIXME: cagney/2003-10-15: This code should walk down the target > >>+ stack looking for a stratum that supports the mechanism. > >>+ Unfortunatly, there isn't a per-target-stack chain to walk round. > >>+ Catch-22. */ > >>and a s/target_ops/target/ transformation. > > > > > >Preferably not target - didn't someone suggest gdbtarg? Or maybe > >gdb_target. > > ... you mean someone actually likes gdbtarg :-) Not all that much. But I really dislike "target". > >>Note that it includes: > >>+ /* Transfer up-to LEN bytes of memory starting at OFFSET. */ > >>+ TARGET_OBJECT_MEMORY > >>I'm going to need that when implementing a per-target > >>CONVERT_FROM_FUNC_PTR_ADDR. > > > > > >How is that different from a memory read, which we've already got? I am > >guessing that it's because you want to support partial memory > >operations (avoid packet size limits), but you never explained your > >goal. > > I previously wrote: > > >In the light of Joel's "upload/download" commands, and lessons (gdb/589) > >learn't from similar interfaces, and a realization that I need this for > >memory: > ... > >- it takes an explicit target vector > >- there are both read and write variants (instead of query) > >- it, what the heck, takes a LONGEST > >- it makes the fact that the method isn't expected to perform a full > >transfer explicit > > gdb/589 is yet another example of how the existing code always did > partial xfers, yet no one noticed. Have a look at how many levels of > GDB code try to locally solve the partial transfer problem when > generic_load is called. > > The only significant difference is the addition of an explicit target > vector. But that's really significant. I should probably comment out > TARGET_OBJECT_MEMORY until a target implements it. Yes, please. Anyway, I see where you're going now. > >>+ /* Map pre-existing objects onto letters. DO NOT do this for new > >>+ objects!!! Instead specify new query packets. */ > > > > > >Could that be a little clearer - I had to read the code a couple of > >times to figure out what you meant. I guess you just want to say that > >there's no need to use single letters? > > The code abuses: > > + > > as a way of generating packets. The entire qK* and qR* packet maps have > been kidnapped by this. The un-approved RedBoot patches did the same > with qM*. > > I'll expand the comment. Do we need a standard terminator here too - colon or semicolon again? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer