Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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?


To me this seems artificial.  I can understand a split along the lines 
of ISA and ABI but not one justified on the grounds of what gdb-server 
needs.  That feels like putting the cart before the horse.

Could I strongly encourage you to at least try to build a bloated GDB 
server so that you (and everyone else) know what the real problems are. 
  I think you will find that the bloat caused by *-tdep.c will be in the 
noise compared to the other things that are draged in.

Could I also encourage you to examine exactly what information you do 
need from gdbarch.  The big ones that that I know of are 
REGISTER_RAW_SIZE() and REGISTER_BYTE().  The way that they are used to 
construct/destruct a G packet are simply wrong.

To repeat an earlier point, I think there needs to be something outside 
of gdbarch that specifie what a G packet layout is and how that G packet 
is mapped to/from a raw-regnum or a native register.  Remember, the G 
packet is part of an unchanging and public interface (I'll resist the 
temptation to suggest specifying it in ASN.1 :-).


> 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.


Jut FYI, core GDB should not know about PC_REGNUM.  A given ISA might be 
able to determine the program stop/resume address (returned via 
read_pc()) from a single raw register.  A second ISA might find it 
necessary to construct that same stop/resume address using 4 separate 
raw registers.

	Andrew