From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16002 invoked by alias); 23 Aug 2002 12:41:23 -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 15537 invoked from network); 23 Aug 2002 12:41:17 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 23 Aug 2002 12:41:17 -0000 Received: by fw-cam.cambridge.arm.com; id NAA12378; Fri, 23 Aug 2002 13:41:13 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma011774; Fri, 23 Aug 02 13:40:54 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2 [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA25599; Fri, 23 Aug 2002 13:40:53 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA19807; Fri, 23 Aug 2002 13:40:51 +0100 (BST) Message-Id: <200208231240.NAA19807@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: Jason R Thorpe , Daniel Jacobowitz , gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. Subject: Re: [patch/rfc] Don't complain about unknown OSABI In-reply-to: Your message of "Wed, 21 Aug 2002 16:26:52 EDT." <3D63F78C.4050001@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 06:07:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-08/txt/msg00750.txt.bz2 > Code isn't the problem here. It's the user-gdb interface. Does the the > user model still work if there is more than one architecture. Not > exploring the user-gdb interaction and instead just hacking code is how > we came to have all the CLI querks we've come to hate :-) > > Anyway, I suspect just forcing the architecture when the OSABI is > changed is the most robust approach: > > > (gdb) set osabi MIPS/GNU/Linux > > Current architecture is NS32K, change to MIPS? (y or n) > > ``the user is always right'' (no matter how silly it is :-). But if gdb doesn't know how to handle the user's request, it doesn't matter how right the user is, they're still going to get garbage out of the debugger. > I think it is also becomming aparent that there are several OSABI involved: > > - the global default > - the current instance > > ``set osabi'' would change the current instance. I think if we had the 'sniffer' code work as follows (I forget the names of the functions, but I think you'll get the drift): abi = sniff_osabi (abfd, allow_user_override); if (! handled_by_this_arch (abi)) { gdb_printf("Don't know how to handle abi '%s' on this architecture, " "using automatic detection", abi->name); abi = sniff_osabi (abfd, force_sniff); } Then each target arch can decide if it knows how to handle an ABI and if not force selection. sniff_osabi would probably do if (allow_user_override && user_override != automatic) return user_override; /* start of auto-sniffer code. */ R.