Re: [PATCH/RFA] Don't gdbarch_init for core files

[Daniel Jacobowitz <drow@mvista.com>]

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.

<nod>

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer