parcelling up struct gdbarch

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

For the benefit of gdbserver, as discussed, I'd like to break the struct
into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
Things which gdbserver should be able to share, like PC_REGNUM and other
things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
would go in the smaller native struct.  They could be fetched from a (split
off from the existing) target specific file, or temporarily added in the
appropriate low-<arch>.c.

Does this sound reasonable?

Also, as a first step I would like to break the data table out of gdbarch.sh
into a separate file.  Is there any reason not to do this?  Then, rather
than introducing another field, I can introduce a second data file for the
native elements.

Native is perhaps not the best name, as e.g. PC_REGNUM need to be known even
in non-native configurations, but calling it gdbarch_target seems wrong to
me.  I'm open to better naming suggestions.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer