From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5862 invoked by alias); 15 Oct 2003 23:09:16 -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 5853 invoked from network); 15 Oct 2003 23:09:15 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 15 Oct 2003 23:09:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3D21D2B89; Wed, 15 Oct 2003 19:09:16 -0400 (EDT) Message-ID: <3F8DD39C.4090007@redhat.com> Date: Wed, 15 Oct 2003 23:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] target read/write partial References: <3F8DC73C.4090205@redhat.com> <20031015223255.GA17644@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00525.txt.bz2 > 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 :-) >> 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. >> + /* 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. >> + /* Minimum outbuf size is (rs->remote_packet_size) - if bufsiz is >> + not large enough let the caller. */ > > > Missing a word there I think. Will fix. Andrew