From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5001 invoked by alias); 28 Oct 2003 22:11:47 -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 4994 invoked from network); 28 Oct 2003 22:11:47 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 28 Oct 2003 22:11:47 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9SMBkM27596 for ; Tue, 28 Oct 2003 17:11:46 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9SMBk617499 for ; Tue, 28 Oct 2003 17:11:46 -0500 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9SMBjju004178; Tue, 28 Oct 2003 17:11:46 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9SMBel03838; Tue, 28 Oct 2003 15:11:40 -0700 Date: Tue, 28 Oct 2003 22:11:00 -0000 From: Kevin Buettner Message-Id: <1031028221140.ZM3837@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [patch/rfc] to_read/write_partial -> to_xfer_partial" (Oct 27, 11:26am) References: <3F9D7F21.6030001@redhat.com> <1031027204631.ZM31164@localhost.localdomain> <3F9D472A.4010205@redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [patch/rfc] to_read/write_partial -> to_xfer_partial Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00822.txt.bz2 On Oct 27, 11:26am, Andrew Cagney wrote: > Subject: Re: [patch/rfc] to_read/write_partial -> to_xfer_partial > >> Per: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00641.html > > > >> > Having taken the change to this point, I'm now wondering if the read/write partial methods should be merged into: > >> > to_xfer_partial (targ, object, annex, > >> > offset, len, > >> > readbuf, writebuf) > >> > as that would make migrating existing targets easier. > > > >> Having implemented bfd-target and remote-target versions > >> to_read/write_partial, I think this switch is going to make life easier. > > > > Could you offer a few more details on why you think that merging the > > read/write methods into a single xfer method will make it easier to > > migrate existing targets? > > There's a tradeoff. You'll notice that I started out with separate > asthetically pleasing read/write methods, but eventually decided the > cost was too high. > > - the existing targets implement a memory centric "xfer". Its going to > be easier [for me] to convert that code to this new xfer variant. > > - both the read and write paths use identical buffer overflow logic, and > its that logic which contains the nasty edge cases and consequent bugs. Is there any reason you can't keep the methods separate, but use a common underlying "xfer" implementation? (Which, I think, is how it's presently done.) In the past, when trying to figure out how an xfer implementation worked, I recall looking at how the read/write stubs called the xfer function. Kevin