Re: Who owns gdbserver?

[Andrew Cagney <ac131313@cygnus.com>]

> 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