Re: parcelling up struct gdbarch

Andrew Cagney
2001-07-13T12:35:00Z

> 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