From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: parcelling up struct gdbarch Date: Fri, 13 Jul 2001 12:35:00 -0000 Message-id: <3B4F4D7F.6010201@cygnus.com> References: <20010713001635.A19524@nevyn.them.org> X-SW-Source: 2001-07/msg00137.html > 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-.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