This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/RFA] Don't gdbarch_init for core files
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