This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Who owns gdbserver?
- To: "John S. Kallal" <jskallal at home dot com>
- Subject: Re: Who owns gdbserver?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 22 Jun 2001 11:42:27 -0400
- Cc: gdb at sources dot redhat dot com, Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- References: <01062113504401.01520@CyberMax>
> 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