From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22558 invoked by alias); 28 Apr 2004 15:42:30 -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 22540 invoked from network); 28 Apr 2004 15:42:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 28 Apr 2004 15:42:29 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3SFgTKI022890 for ; Wed, 28 Apr 2004 11:42:29 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3SFgSv01735; Wed, 28 Apr 2004 11:42:28 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ACD522B9D; Wed, 28 Apr 2004 11:42:31 -0400 (EDT) Message-ID: <408FD0E7.3000300@gnu.org> Date: Wed, 28 Apr 2004 15:42:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfa] fix call-dummies for hppa References: <20040424190231.GC2923@tausq.org> In-Reply-To: <20040424190231.GC2923@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00629.txt.bz2 > This fixes a few bugs in the 32-bit version of the hppa push_dummy_call > method. > > Tested against hppa2.0w-hp-hpux11.11 and hppa-linux. Which compilers? I'm suspicious of GCC - it too often gets struct parameters and return values internally consistent but wrong :-( > All of structs.exp pass, there are still some failures in call-sc.exp > and callfuncs.exp. In the latter case it appears most are due to > problems with calling malloc() in the inferior (at least on hppa-linux). > We simply allocate the appropriate amount of stack space and put > arguments into their proper slots. */ > - > + Be careful of white space change, this shouldn't be included. If you want to fix some indention just do it separatly. > CORE_ADDR > hppa32_push_dummy_call (struct gdbarch *gdbarch, CORE_ADDR func_addr, > struct regcache *regcache, CORE_ADDR bp_addr, > int nargs, struct value **args, CORE_ADDR sp, > int struct_return, CORE_ADDR struct_addr) > { > - /* NOTE: cagney/2004-02-27: This is a guess - its implemented by > - reverse engineering testsuite failures. */ > - (I've now got a copy of the 32-bit ABI but it doesn't help much) > /* Stack base address at which any pass-by-reference parameters are > stored. */ > CORE_ADDR struct_end = 0; > @@ -781,12 +779,15 @@ hppa32_push_dummy_call (struct gdbarch * > /* Two passes. First pass computes the location of everything, > second pass writes the bytes out. */ > int write_pass; > + > for (write_pass = 0; write_pass < 2; write_pass++) > { > CORE_ADDR struct_ptr = 0; > - CORE_ADDR param_ptr = 0; > - int reg = 27; /* NOTE: Registers go down. */ 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; > int i; > + int small_struct = 0; > + > for (i = 0; i < nargs; i++) > { > struct value *arg = args[i]; > @@ -795,6 +796,7 @@ hppa32_push_dummy_call (struct gdbarch * > stack, and [possibly] passed in a register. */ > char param_val[8]; > int param_len; > + > memset (param_val, 0, sizeof param_val); > if (TYPE_LENGTH (type) > 8) > { > @@ -813,27 +815,76 @@ hppa32_push_dummy_call (struct gdbarch * > /* Integer value store, right aligned. "unpack_long" > takes care of any sign-extension problems. */ > param_len = align_up (TYPE_LENGTH (type), 4); > + white space > store_unsigned_integer (param_val, param_len, > unpack_long (type, > VALUE_CONTENTS (arg))); > } > + 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); > + } > else > { > - /* Small struct value, store right aligned? */ > param_len = align_up (TYPE_LENGTH (type), 4); > + > + /* Small struct value are stored right-aligned. */ > memcpy (param_val + param_len - TYPE_LENGTH (type), > VALUE_CONTENTS (arg), TYPE_LENGTH (type)); > + > + /* Structures of size 5, 6 and 7 bytes are special in that > + the higher-ordered word is stored in the lower-ordered > + argument, and even though it is a 8-byte quantity the > + registers need not be 8-byte aligned. */ > + if (param_len > 4) > + small_struct = 1; > } > + > param_ptr += param_len; > - reg -= param_len / 4; > + if (param_len == 8 && !small_struct) > + param_ptr += (param_ptr & 4); align_up? Otherwize, yep, thanks for fixing this. Andrew