From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23082 invoked by alias); 9 Jun 2002 20:19:46 -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 23075 invoked from network); 9 Jun 2002 20:19:44 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 9 Jun 2002 20:19:44 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3CF183EA5; Sun, 9 Jun 2002 16:19:41 -0400 (EDT) Message-ID: <3D03B85D.8050605@cygnus.com> Date: Sun, 09 Jun 2002 13:19:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc3) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: MIPS ABI selection References: <20020609031656.GA2529@nevyn.them.org> <3D03A944.1000704@cygnus.com> <20020609192840.GA13703@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00156.txt.bz2 > -- Adding the macro MIPS_DEFAULT_ABI to all MIPS targets. >> >> Remember, all the mips/tm-*.h files are going away so this isn't really >> going to help. Instead, I think a ``(gdb) set mips abi .. auto o32 >> ...'' command would be far more useful. Another place the code could >> look is the ABI from the previous architecture. > > > That paragraph is three things: > tm-*.h files are going away: Yes, certainly, and when they do they > will become OSABIs presumably. Those new places don't exist yet. When > they do the default ABI should go in them, and for now I want to put it > in the right place so that it will be picked up and moved over when the > time is right. What's wrong with that? I don't expect this to happen. As you point out, the mips_find_abi_section() makes this all somewhat redundant. > "set mips abi": Certainly it's useful, but I'd say it was completely > unrelated to the purpose of my patch. My understanding of the purpose of the patch was to change the default ABI to O32. Given that won't always be correct, I think a user command, (rather than a source code change) is needed to handle the edge conditions. > ABI from the previous architecture: I don't want to do that. I believe > that generating a new architecture should be completely independent of > the previous architecture. If we figured it out the first time we can > figure it out again. Check how ``set endian big'' works or the ABI mechanism in the CRIS target. It forces an architecture update with just one field set. The rest of the architecture information still being taken from the previous architecture. > -- Some additional MIPS targets >> >> Er, we're trying to get the number of MIPS targets down to zero. > > > GCC supports configuring for those targets. Binutils supports > configuring those targets. In both cases they get a special default > ABI that doesn't match GDB's. I think that makes the new targets quite > justified. I think GDB should be able to rely on build and run-time information provided by BINUTILS (bfd/config.bfd, ...) when making this selection. I'm also puzzled as to why it was included in the patch. > _HOWEVER_: After I commit the bit to use ".mdebug.abi*" sections, we > will always get the ABI for GCC-produced binaries correct, at least as > far back as I can find GCC releases. After that point I no longer care > what the default case says. Right! > How about I just commit the part which > says "if no tm- file overrides this, default to O32" and the bit which > removes the default case (which accesses a lot of target macros, ew)? You mean: #ifdef MIPS_DEFAULT_ABI .. #else if (not set) set to O32;? #endif My problem is that I know it is going to break something. Hence the need to be able to force the ABI at runtime with a command. Andrew