From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2535 invoked by alias); 2 Aug 2002 17:22:57 -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 2524 invoked from network); 2 Aug 2002 17:22:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 2 Aug 2002 17:22:56 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 237703CDC; Fri, 2 Aug 2002 13:22:56 -0400 (EDT) Message-ID: <3D4ABFEF.50807@ges.redhat.com> Date: Fri, 02 Aug 2002 10:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020708 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com, cagney@redhat.com, kevinb@redhat.com, echristo@redhat.com Subject: Re: [RFC] Mips, N32, cc, gcc, and gdb (longish) References: <3D49DCF8.AB4C6718@redhat.com> <20020802015734.GA28572@nevyn.them.org> <3D49ED50.E6A46CF4@redhat.com> <20020802024556.GA26508@nevyn.them.org> <3D49F5F7.C2135261@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00056.txt.bz2 > Daniel Jacobowitz wrote: >> > > > 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. > >> > >> > Right -- but this thread concerns what to do if that DOESN'T happen. >> > >> > In answer to your comment, I believe the code currently in GDB >> > already handles the case you describe, both for CC and for GCC. >> > So what I'm discussing here will bring stack-passing into line >> > with register-passing. >> > >> > However, you may be right that I need to check for endian-ness >> > in my proposed change. I haven't tested that. > >> >> I'm not actually sure if it's the same if statement. > > > It's not. > > >> Certainly GDB and GCC do not agree on mipsel-linux. >> >> I'd say the proper thing to do is to see that GCC is fixed, not to lay >> contingency plans... > > > Well then, I hope somebody else replies! ;-) I hope it wasn't me :-) GCC need to be fixed. Either they need to define a new abi that specifies all their breakage OR they fix it to match the offical abi. I have a sinking feeling that they'll do both. Andrew