From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16029 invoked by alias); 19 Aug 2002 23:03:12 -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 16021 invoked from network); 19 Aug 2002 23:03:11 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 19 Aug 2002 23:03:11 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 02FD03DC6; Mon, 19 Aug 2002 19:03:07 -0400 (EDT) Message-ID: <3D61792B.1020708@ges.redhat.com> Date: Mon, 19 Aug 2002 16:03:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Don't complain about unknown OSABI References: <3D5FC00D.50001@ges.redhat.com> <20020818154927.GA20358@nevyn.them.org> <3D5FCE6A.9080308@ges.redhat.com> <20020819161543.GA10137@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00564.txt.bz2 >> I know. Being able to print the OSABI would help (set/show abi). > > > Yes. Did you look at the patch posted two or three days ago to add > set/show commands? Yes, and it is a hard command to implement right (or even figure out what implement right even means!). > Actually, as he probably doesn't have copyright papers on file, I may > whip something equivalent together today. Be sure to wear a seatbelt, the problem is harder than it looks. >> I think it should ask BFD. BFD can then go and look at the target >> tuple. That would mean that BFD and GDB are ``on the same page''. See >> the hacks I've got GDB pulling to figure out the default architecture. > > > This doesn't make sense to me. The different is that BFD and GDB both > have a notion of architecture; but BFD has no notion of OSABI. The > distinguishing markers we use come from the system libraries as often > as not. Something in binutils knows what the basic OS is. The linker often knows to brand the executable a certain way (although increasingly it is the compiler that is telling the linker everything). What executable, for instance, does: as -o s.o /dev/null ld s.o create? > My suggestion: First we'd add set/show osabi, with settings for each > (known? Registered? I think registered.) OSABI. Then it would also > have "default" and "auto". The difference is that auto would use the > detection mechanism and fall back to default if necessary, and default > would be fixed. Then we'd set the default in one of two ways: > > - Specify the default value in configure.tgt > - Do some analysis of the target triplet in osabi.c > > I'm inclined to go with a list of registered OSABI's, It should match against the registered OSABI's. > and to set the > default at configure time. How's that sound? GDB uses ../bfd/config.bfd to find the default architecture. I think this has made our lives much easier -- gdb's and bfd's defaults match and we don't have to maintain anything. It really is a ``free lunch'' :-) Is there an equivalent for the OS/ABI? If we can pick that default up from binutils then we also get that for free. On the other hand if we start wiring this stuff into configure.tgt (duplicating ld/gcc) we take on an additional maintenance task. Andrew