From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10226 invoked by alias); 2 Mar 2005 09:08:38 -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 9886 invoked from network); 2 Mar 2005 09:08:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Mar 2005 09:08:21 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2298K4H024708 for ; Wed, 2 Mar 2005 04:08:20 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2298KK08585 for ; Wed, 2 Mar 2005 04:08:20 -0500 Received: from cygbert.vinschen.de (vpn50-3.rdu.redhat.com [172.16.50.3]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j2298I5s005291 for ; Wed, 2 Mar 2005 04:08:19 -0500 Received: by cygbert.vinschen.de (Postfix, from userid 500) id AF12F57D78; Wed, 2 Mar 2005 10:08:10 +0100 (CET) Date: Wed, 02 Mar 2005 09:08:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] New GDB target iq2000 Message-ID: <20050302090810.GB28084@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050222114141.GA18314@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-SW-Source: 2005-03/txt/msg00015.txt.bz2 Hi Jim, On Mar 1 17:11, Jim Blandy wrote: > I think all the calls to set_gdbarch__bit can be left out, > because they just re-state the default values. Same for > decr_pc_after_break, no? I'm ok with removing decr_pc_after_break, but I'd rather leave the set_..._bit calls in, so that one can see on the first glance how the datatypes are defined for this target. Actually I'd prefer to have them defined in all targets explicitely. That way, a casual reader of the code doesn't have to guess if the programmer left them out accidentally or deliberately, especially in border cases as long long or long double. > +static enum return_value_convention > +iq2000_return_value (struct gdbarch *gdbarch, struct type *type, > [...] > > The other return_value implementations I've seen allow one to pass > both a readbuf and a writebuf, and do the read before the write. I > can't find any place where it's actually used this way, but it seems > to be allowed by the interface. In any case, it's easy enough to make > iq2000_return_value behave like the others. I'm with Daniel here. readbuf and writebuf are mutually exclusive, at least from a logical point of view. If the order of requesting the value of readbuf and writebuf changes the behaviour of the gdbarch_return_value function, than that's a design flaw of gdbarch_return_value and should be fixed. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc.