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

[Jason R Thorpe <thorpej@wasabisystems.com>]

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 <thorpej@wasabisystems.com>