Re: Who owns gdbserver?

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Fri, Jun 22, 2001 at 11:42:27AM -0400, Andrew Cagney wrote:
> 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.

Definitely.

My current inclination is that, after we enumerate precisely what
interfaces are needed, we may need to break some of the nat and tdep
files up into smaller pieces, so that gdbserver can link in the parts
it really needs - and the parts it can reasonably include the support
code for.

[To be honest, my gut instinct is to also start moving
platform-specific code to config directories at the same time.  I don't
know if that would meet with general approval, though]

> 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).

Well, actually, we had to address this at MontaVista.  We were
fortunate in that we had a relatively easy way out - we build a cross
gdb, and a target gdb for those who prefer native debugging (or want
threads, which gdbserver does not yet handle... etc.)  The target gdb
is cross compiled, and gdbserver is built then.  Building it along with
the cross gdb would not be hard, though - we'd just need to standardize
on an "appropriate" variable for the target compiler if it was
available - something like $CC_FOR_TARGET, but since the eventual
target platform is not really our "target" at this stage of the build
that might not be the best choice.

> 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).

More tightly integrated is definitely also my preference, if you
couldn't tell from above.  I'm willing to work to make that happen.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer