From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2104 invoked by alias); 12 May 2002 03:46:15 -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 2097 invoked from network); 12 May 2002 03:46:14 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 May 2002 03:46:14 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 176kIi-0006a2-00; Sat, 11 May 2002 23:45:36 -0400 Date: Sat, 11 May 2002 20:46:00 -0000 From: Daniel Jacobowitz To: Jason R Thorpe , Andrew Cagney , Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Don't gdbarch_init for core files Message-ID: <20020512034536.GA25145@nevyn.them.org> 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> <20020511203035.H3435@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020511203035.H3435@dr-evil.shagadelic.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00418.txt.bz2 On Sat, May 11, 2002 at 08:30:35PM -0700, Jason R Thorpe wrote: > 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). Just a guess - debugging a core file without an original binary? > > > 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer