From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Stan Shebs Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Current (non-) state of gdbserver Date: Wed, 11 Jul 2001 13:44:00 -0000 Message-id: <3B4CBAAC.8030205@cygnus.com> References: <20010710234505.A5814@nevyn.them.org> <3B4CA2DA.EB9DCB43@apple.com> X-SW-Source: 2001-07/msg00104.html > > As Andrew observes, you'll probably get tangled up in dependencies, > but those are likely to be mistakes in GDB's architecture - there's > no good reason why lowest-level native and target support (which is > all that gdbserver needs) has to be making references to user-interface > code and the like. Just FYI, it isn't just multi-arch. ui-out/ui-file/.... are also having an impact effect. In their case a little re-aranging would certainly help (create cleanups.[hc]?, file-utils.[hc]?, ...). > Thought 1: split the arch vector into a general vector and a nano-vector > with only the register definitions and such. If we really don't care > about the extra footprint from unused arch code (either because it's > small, or we know linker will discard), then instead you could have > an optional -ui.c to be a home for target-specific commands. Here, I think trying to split things up would be roughly equivalent to re-aranging those brand new deck chairs(1) :-) This is because everything depends on the single macro REGISTER_RAW_SIZE(). As I noted in another e-mail, I think there needs to be something that specifies the protocol register numbering [rawnum] and the G packet layout that is completly independant of multi-arch and, for the G packet, GDB. On a normal GDB, the conversion sequence: nat-register layout | |(*-nat.c) | raw register layout | |(*frame*) | cooked register layout occures. (nat layout is what is on the HOST OS IF, raw layout is what is used by GDB's register cache and target vector, cooked layout is what is used by read_register_frame(frame, ...) et.al.) If you introduce the remote protocol into the picture then the sequence is changed to either: nat-register layout | |(gdbserv/*nat*) | G packet layout | |(remote.c) | raw reg layout | |(*frame*) | cooked reg layout or nat-register layout | |(*-nat.c) | raw register layout | |(gdbserver) | G packet layout | |(remote.c) | raw register layout | |(frame*.c) | cooked register layout depending on how ``pure'' you want things :-) Anyway, within the above, I think the `G packet' and possibly the `raw register layout' need to be defined out side of *-tdep.c. If this is done then the rest of the problem becomes managable. See also: http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=122&database=gdb Anyway, to throw a spanner in the works, (given some comments from Eli) IRIX could easily end up with a *-nat.c that supports two different architectures. Solaris is similar. I suspect the i386-64 chip could be the same. enjoy, Andrew -- (1) Rearanging deck chairs on the titanic.