From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23032 invoked by alias); 19 Aug 2002 16:15:13 -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 23024 invoked from network); 19 Aug 2002 16:15:11 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Aug 2002 16:15:11 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17gpBN-0003sF-00; Mon, 19 Aug 2002 11:15:10 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17gpBv-0002gk-00; Mon, 19 Aug 2002 12:15:43 -0400 Date: Mon, 19 Aug 2002 09:15: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: <20020819161543.GA10137@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5FCE6A.9080308@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00550.txt.bz2 On Sun, Aug 18, 2002 at 12:42:18PM -0400, Andrew Cagney wrote: > >On Sun, Aug 18, 2002 at 11:41:01AM -0400, Andrew Cagney wrote: > > > >>Hello, > >> > >>The attached patch removes the warning message that is printed when the > >>OSABI is unknown (all the sniffers failed). > >> > >>When debugging an embedded executable, there is no OSABI info. Hence I > >>don't think the warning should be issued. This can be seen when > >>debugging a GCC created, mips-elf executable. > >> > >>thoughts? > >>Andrew > > > > > >I like it. I asked for this change about two months ago when I noticed > >it on mips-elf. And there's a typo in the message you're removing, > >too. > > >[On the related hand, we just had some reports about a case where the OS > >ABI is isn't detected (on uClibc) - do you think a (configure.tgt based > >or *.mt based rather than in a header, I think) way to specify the > >default OS ABI based on the target triplet would be appropriate? > > 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? Actually, as he probably doesn't have copyright papers on file, I may whip something equivalent together today. > 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. 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, and to set the default at configure time. How's that sound? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer