From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14267 invoked by alias); 2 Aug 2002 01:57:31 -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 14260 invoked from network); 2 Aug 2002 01:57:30 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 2 Aug 2002 01:57:30 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17aRh5-0001lv-00; Thu, 01 Aug 2002 20:57:31 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17aRh8-0007RC-00; Thu, 01 Aug 2002 21:57:34 -0400 Date: Thu, 01 Aug 2002 18:57:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com, cagney@redhat.com, kevinb@redhat.com, echristo@redhat.com Subject: Re: [RFC] Mips, N32, cc, gcc, and gdb (longish) Message-ID: <20020802015734.GA28572@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com, cagney@redhat.com, kevinb@redhat.com, echristo@redhat.com References: <3D49DCF8.AB4C6718@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D49DCF8.AB4C6718@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00047.txt.bz2 On Thu, Aug 01, 2002 at 06:14:32PM -0700, Michael Snyder wrote: > OK, I think I've made this as concise as practical. ;-) > > In case the difference between Irix cc and gcc does not get > fixed (and I mean specifically the difference concerning > alignment of small struct arguments), I'd like to discuss > "fixing" gdb so that it will work correctly with both. > > I've found a testcase for this problem in call-ar-st.exp: > > (gdb) print print_long_arg_list (a, b, c, d, e, f, *struct1, > *struct2, *struct3, *struct4, *flags, *flags_combo, > *three_char, *five_char, *int_char_combo, > *d1, *d2, *d3, *f1, *f2, *f3) > > This fails (or doesn't) depending on whether a small struct > is left-justified or right-justified when it is pushed onto > the stack (ie, when it is the 5th or higher argument). > > The code in mips_push_arguments that controls this is: > > if (MIPS_STACK_ARGSIZE == 8 && > (typecode == TYPE_CODE_INT || > typecode == TYPE_CODE_PTR || > typecode == TYPE_CODE_FLT) && len <= 4) > longword_offset = MIPS_STACK_ARGSIZE - len; > else if ((typecode == TYPE_CODE_STRUCT || > typecode == TYPE_CODE_UNION) && > TYPE_LENGTH (arg_type) < MIPS_STACK_ARGSIZE) > longword_offset = MIPS_STACK_ARGSIZE - len; > } > > As it is written, it "works" with gcc but fails with cc. > > Kevin proposed this change to me (I don't remember if > he has submitted it yet): > > *** > typecode == TYPE_CODE_UNION) && > ! TYPE_LENGTH (arg_type) < MIPS_STACK_ARGSIZE) > longword_offset = MIPS_STACK_ARGSIZE - len; > --- > typecode == TYPE_CODE_UNION) && > ! TYPE_LENGTH (arg_type) < MIPS_STACK_ARGSIZE > ! && tdep->mips_abi != MIPS_ABI_N32) > longword_offset = MIPS_STACK_ARGSIZE - len; > *** > > With this change, it "works" with cc, but fails with gcc. > > I want to discuss the following change, which should > make it "work" with both cc and gcc (given the current > behavior of both): > > *** > typecode == TYPE_CODE_UNION) && > ! TYPE_LENGTH (arg_type) < MIPS_STACK_ARGSIZE) > longword_offset = MIPS_STACK_ARGSIZE - len; > --- > typecode == TYPE_CODE_UNION) && > ! TYPE_LENGTH (arg_type) < MIPS_STACK_ARGSIZE > ! && (gcc_p ||tdep->mips_abi != MIPS_ABI_N32)) > longword_offset = MIPS_STACK_ARGSIZE - len; > *** > > > This of course makes gdb's behavior dependent on which > compiler it detects. > > There is one problem: there is no variable "gcc_p" within > the scope of mips_push_arguments, because PUSH_ARGUMENTS > does not pass it. So that would need to be solved, > possibly by modifying the definition of PUSH_ARGUMENTS. > > Comments? Comment - you're on a slippery slope. I know of at least one other variation in this area; for structures of less than a word SGI CC shifts them in register only for big endian targets, and not for little endian (on the old versions of CC which support little endian). There comes a point where we just need to get GCC fixed, and I think this is it. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer