RFA: gdbarch_free

Andrew Cagney ac131313@cygnus.com
Tue Mar 21 00:48:00 GMT 2000


Jim Blandy wrote:
> 
> > > > > >From memory, I figured that if an _initialize* function failed to create
> > > > > a gdbarch the process was somewhat hosed and calling internal_error()
> > > > > was probably the best thing to do.
> > >
> > > > This situation could arise if someone adds support for a new variant
> > > > of my architecture, but hasn't updated GDB yet.
> > >
> > > So the real question is, is this an internal_error() and how should
> > > it be handled?  I can be convinced either way on this :-)
> >
> > No, it's okay, I'll just drop the memory.  I withdraw the patch.
> 
> Well, actually...

:-)

> I don't think this is an internal error.  It's simply a case where GDB
> has been given an executable that it doesn't recognize.  That
> executable may have been produced by a completely different toolchain.

Ah, I'd not thought of it that way. Yes, very good point. While I can
try to insist that GDB / BFD are kept consistent, I can't impose that
requirement on the real world.

Your change is approved.

I'll see about clarifying the spec for gdbarch_init_ftype so that it
makes it clear that not recognizing the architecture is common and
should be handled cleanly.

As a second issue, there should be a test that checks that BFD/GDB are
in sync with regard to architecture changes.  Something like a test that
first queries GDB for all supported architectures and then feeds each
back to GDB..  Anyone interested in learning how to write tests? :-)

	Andrew


More information about the Gdb-patches mailing list