From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Current (non-) state of gdbserver Date: Wed, 11 Jul 2001 12:03:00 -0000 Message-id: <3B4CA2DA.EB9DCB43@apple.com> References: <20010710234505.A5814@nevyn.them.org> X-SW-Source: 2001-07/msg00098.html Daniel Jacobowitz wrote: > > Based on the lack of response I got last time I inquired about gdbserver, > I'd say that no one has really picked it up since Stan stepped back. It > hasn't built in a while; the multiarch support completely stops it from > working, on the targets I tried at least (ppc-linux and mips-linux). > > Unless someone steps up with something already done (if you're out there, > we're waiting...), I'm going to start working on this. I'm not sure how > multiarch will fit in to gdbserver in the future, but for now my intent is > to bloat it somewhat with the necessary support code. It'll probably > involve splitting a lot of tdep files into two pieces. 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. 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. Thought 2: foo-nat.c will probably need to be split, again foo-ui.c could be a home for higher-level and symbolic stuff. Thought 3: AIX is especially ugly to handle, because you need to make a ptrace call and pick apart OS-supplied structures even to find the entry point. Might even need a protocol addition to get it to work. > I'd also like to start building gdbserver by default on platforms which > support it (and I have patches to extend the list a bit). That way we can > at least notice this sort of thing... An excellent idea. One thing I wanted to do as part of this was to move gdbserver out of its subdirectory, since by the time you're done integrating with the rest of GDB sources, you should only have one file unique to gdbserver (main()), and the semi-duplicated Makefile.in make trouble. Stan