From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6503 invoked by alias); 28 Apr 2004 15:58:00 -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 6491 invoked from network); 28 Apr 2004 15:57:58 -0000 Received: from unknown (HELO pippin.tausq.org) (64.81.244.94) by sources.redhat.com with SMTP; 28 Apr 2004 15:57:58 -0000 Received: by pippin.tausq.org (Postfix, from userid 1000) id 6ACFECD299; Wed, 28 Apr 2004 08:58:03 -0700 (PDT) Date: Wed, 28 Apr 2004 15:58:00 -0000 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfa] fix call-dummies for hppa Message-ID: <20040428155803.GN3965@tausq.org> Reply-To: Randolph Chung References: <20040424190231.GC2923@tausq.org> <408FD0E7.3000300@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <408FD0E7.3000300@gnu.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-04/txt/msg00633.txt.bz2 > Which compilers? I'm suspicious of GCC - it too often gets struct > parameters and return values internally consistent but wrong :-( gcc only; I don't have access to the hp compilers. However, Dave (the hppa gcc maintainer) is quite careful about these things, so I think they are correct ;-) > Be careful of white space change, this shouldn't be included. If you > want to fix some indention just do it separatly. ok, there were some stray tabs in the file so i was cleaning them up along the way, but i'll remove that from this diff. > (I've now got a copy of the 32-bit ABI but it doesn't help much) this is the som runtime doc? it's not particularly clear about small structs..... > the comment doesn't match the assignment. > > >+ /* The first parameter goes into sp-36, each stack slot is 4-bytes. > >*/ > >+ CORE_ADDR param_ptr = 32; it does, actually, because the param_ptr is incremented by 4 for each argument, so the first one goes to 36. > >+ else if (TYPE_CODE (type) == TYPE_CODE_FLT) > >+ { > > more comments (the rest is well commented), ``&& TYPE_LENGTH () == 4'' > test needed? > > >+ param_len = align_up (TYPE_LENGTH (type), 4); > >+ memcpy (param_val, VALUE_CONTENTS (arg), param_len); yes, this bit is wrong. i found some more bugs in this function. will send a new version with the whitespace changes removed and comments added. thanks, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/