From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30994 invoked by alias); 12 May 2002 03:30:38 -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 30968 invoked from network); 12 May 2002 03:30:36 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 12 May 2002 03:30:36 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id D3E6E9869; Sat, 11 May 2002 20:30:35 -0700 (PDT) Date: Sat, 11 May 2002 20:30:00 -0000 From: Jason R Thorpe To: Andrew Cagney Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Don't gdbarch_init for core files Message-ID: <20020511203035.H3435@dr-evil.shagadelic.org> Reply-To: thorpej@wasabisystems.com Mail-Followup-To: Jason R Thorpe , Andrew Cagney , Michael Snyder , gdb-patches@sources.redhat.com References: <20020509185824.U3435@dr-evil.shagadelic.org> <3CDB38BB.4030807@cygnus.com> <20020509212134.W3435@dr-evil.shagadelic.org> <3CDDD7ED.9080302@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CDDD7ED.9080302@cygnus.com>; from ac131313@cygnus.com on Sat, May 11, 2002 at 10:48:13PM -0400 Organization: Wasabi Systems, Inc. X-SW-Source: 2002-05/txt/msg00417.txt.bz2 On Sat, May 11, 2002 at 10:48:13PM -0400, Andrew Cagney wrote: > is [almost] no different to deleting the call - GDB isn't yet built with > multiple architectures so the two architectures will always be identical. > > Looking at the date/author of the original patch [and making a wild > guess], I think the original change was related to debugging 32 bit core > files on a SPARC64 system. Michael? Well, I know Solaris dumps a 32-bit core file for a 32-bit binary, and a 64-bit core file for a 64-bit binary. I simply fail to see any reason why you'd want to re-initialize the gdbarch for a core file. I guess I really do need to know why the change was added in the first place (the message with the original patch doesn't describe the problem the patch is trying to solve). > For the moment, bfd's compatible() might be the best test (does it give > the effect you're looking for?). The other approach is to enhance the > relevant architecture vectors so that they don't change the architecture > for cases like this. I think, eventually, the ABI/OS stuff will help > solve this problem. Anway, what ever the change, it will need plenty > comments :-) Well, the question is -- how are the arch vectors supposed to tell when they're supposed to update it and when they're not supposed to update it? Sigh, in any case, the current situation really sucks, as core file handling is somewhat broken on any platform that has gdbarch'd OS ABI handling. -- -- Jason R. Thorpe