From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: "John S. Kallal" Cc: gdb@sources.redhat.com, Daniel Jacobowitz Subject: Re: Who owns gdbserver? Date: Fri, 22 Jun 2001 08:42:00 -0000 Message-id: <3B336763.2090807@cygnus.com> References: <01062113504401.01520@CyberMax> X-SW-Source: 2001-06/msg00182.html > On a related note, I'm trying to think of a way to eliminate some of the >> crasser code duplication between gdb and gdbserver - or rather, right now >> it's mostly a lack of code duplication, causing gdbserver not to work >> terribly well. The ideal solution would be to abstract the details of >> managing a Unix inferior via ptrace to the point where I can link the same >> files into gdbserver, but there are of course some intractable issues - >> setting the shared library debugging breakpoint, for instance. Before I >> begin working on this, does anyone have any thoughts? Is someone out there >> working on a similar thing before I waste my time? > > > > Currently gdbserver is only build when you go into the gdbserver's directory > and build it. I think that you should 1st change gdb's configure/make system > to alway build gdbserver by default on system where gdbserver is > supported. That way when ever any change to the shared code > base of gdb/gdbserver creates bit rot, the problem will be quickly > noticed. The main reason that GDBSERVER is breaking is that gdb targets are being converted to multi-arched (read cleaned up). The multi-arch mechanism isn't compatible with the way GDBSERVER has been abusing (?) GDB's interfaces to get to the things it wants. I don't don't want this multi-arch cleanup to stagnate because people feel that GDBSERVER should continue to build. Instead, I think the people using GDBSEVER should be looking at that code and figuring out the exact interfaces that are needed and get them properly defined. As a second problem. In many cases, I don't think building GDBSERVER actually makes sense. Consider a typical case - user doing a cygwin-X-embedded-linux gdbserver (host=cygwin, target=linux, build=cygwin?). GDBSERVER needs to be compiled with a cygwin-X-linux compiler and the configury for that isn't trival - it means that you're trying to canadian cross compile GDBSERVER (and GDB). Both these problems leave GDBSERVER at a cross road. It can either become more tightly integrated into GDB (kind of my preference) or start to distance its self (becoming a separate independant program like the stubs). Andrew