From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5597 invoked by alias); 20 Aug 2002 01:55:07 -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 5590 invoked from network); 20 Aug 2002 01:55:06 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 20 Aug 2002 01:55:06 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17gyEd-0004bG-00; Mon, 19 Aug 2002 20:55:08 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17gyFC-0003G3-00; Mon, 19 Aug 2002 21:55:42 -0400 Date: Mon, 19 Aug 2002 18:55:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Don't complain about unknown OSABI Message-ID: <20020820015542.GA12371@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jason R Thorpe , gdb-patches@sources.redhat.com References: <3D5FC00D.50001@ges.redhat.com> <20020818154927.GA20358@nevyn.them.org> <3D5FCE6A.9080308@ges.redhat.com> <20020819161543.GA10137@nevyn.them.org> <3D61792B.1020708@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D61792B.1020708@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00573.txt.bz2 On Mon, Aug 19, 2002 at 07:03:07PM -0400, Andrew Cagney wrote: > > >>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. Exactly my point. There is no OS/ABI equivalent; BFD doesn't know what it is, and doesn't need to. I'll try to put this together tomorrow. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer