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