This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: gdbarch_free
> > > > >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.
GDB gets the architecture and the machine (a variant within an
architecture, like 32-bit or 64-bit) from BFD. BFD gets the
architecture from the ELF header's e_machine field (note the
unfortunate conflict in terminology), and gets the machine by masking
off some bits of the ELF header's e_flags field.
Suppose e_flags uses a three-bit field to identify the machine
variant, and uses 001 and 010 to identify two existing variants. In
my foo_gdbarch_init function, I can recognize 001 and 010, but what
should I do with other values?
If I'm using a newer toolchain with an older GDB executable, this
situation could certainly arise, and GDB should report it nicely.
I guess I don't see the rationale for assuming that nobody will ever
put anything in an executable file that some GDB *_gdbarch_init
function won't recognize. GDB should print an error message.
This isn't an internal error: the source of the data is external.