Who owns gdbserver?

Who owns gdbserver?

[Daniel Jacobowitz]

No one admits to it, in MAINTAINERS at least...

I am considering some fairly invasive changes to it, between some signal
problems I've been having, more Linux ports, and threads.  It would be nice
to establish a clear owner before I do that.

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?

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

Re: Who owns gdbserver?

[J.T. Conklin]

>>>>> "Daniel" == Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:
Daniel> No one admits to it, in MAINTAINERS at least...

I think Stan did, among other things.  As I recall, he realized that
he wasn't in a position to maintain things properly and stepped back
from that role.  No one picked up it up since then.

I am interested in the future of the remote protocol, and remote.c and
gdbserver by extension.  I am the remote.c co-maintainer, and have
been known to hack on gdbserver from time to time.  But mainly that's
minor cleanup and adding support for additional NetBSD ports.

Daniel> I am considering some fairly invasive changes to it, between
Daniel> some signal problems I've been having, more Linux ports, and
Daniel> threads.  It would be nice to establish a clear owner before I
Daniel> do that.

I'm not sure I'm up to the task of taking on gdbserver on a full time 
basis, but as a blanket-write-priv maintainer and given my interests
with remote, I'll certainly help you along.

Daniel> On a related note, I'm trying to think of a way to eliminate
Daniel> some of the crasser code duplication between gdb and gdbserver
Daniel> - or rather, right now it's mostly a lack of code duplication,
Daniel> causing gdbserver not to work terribly well.

This has been a outstanding issue for some time.  


        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Who owns gdbserver?

[Andrew Cagney]

> Daniel> No one admits to it, in MAINTAINERS at least...
> 
> I think Stan did, among other things.  As I recall, he realized that
> he wasn't in a position to maintain things properly and stepped back
> from that role.  No one picked up it up since then.


Yes, that is correct.  I'll update the hall of fame.

 
> I'm not sure I'm up to the task of taking on gdbserver on a full time 
> basis, but as a blanket-write-priv maintainer and given my interests
> with remote, I'll certainly help you along.
> 
> Daniel> On a related note, I'm trying to think of a way to eliminate
> Daniel> some of the crasser code duplication between gdb and gdbserver
> Daniel> - or rather, right now it's mostly a lack of code duplication,
> Daniel> causing gdbserver not to work terribly well.
> 
> This has been a outstanding issue for some time.  



I know of the following:

	o	G packet layout

		Here it has been suggested that
		some G packet spec be created so that
		both GDb and GDBSERVER can use it with
		out duplicating that spec.

	o	other arch info

		Core GDB is using multi-arch which means
		that gdbserver can no longer use the
		the current suite of macros with out some
		level of change.

	o	ptrace et.al.

		Since these tend to use gdbarch info they
		have the same problem.

Andrew

Re: Who owns gdbserver?

[Quality Quorum]

On Thu, 28 Jun 2001, Andrew Cagney wrote:

> 
> > 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.
> 
> 
> Sounds good in theory, there is a catch-22 though.  Doing any cleanup is 
> a lot easier with everything multi-arch.
> 
> I'm happy for, short term, there to be a slightly bloated GDBserver, if 
> it means that people concentrate more on getting things multi-arched.

IMHO, the only thing truly shared between gdbserver and gdb
is register map - so it seems feasible to me to keep gdbserver
as an entity completely separate from gdb. 

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: Who owns gdbserver?

[Andrew Cagney]

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


Sounds good in theory, there is a catch-22 though.  Doing any cleanup is 
a lot easier with everything multi-arch.

I'm happy for, short term, there to be a slightly bloated GDBserver, if 
it means that people concentrate more on getting things multi-arched.

	Andrew

Re: Who owns gdbserver?

[Daniel Jacobowitz]

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

Re: Who owns gdbserver?

[Andrew Cagney]

> 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

Re: Who owns gdbserver?

[John S. Kallal]

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

If possible, it would also be nice to to have gdb's 'make check' command 
automaticly run the testsuite on system that support gdbserver and a TCP/IP 
network loopback.  Again this would help detect bit rot in in the code
that is common to both gdb and gdbserver.
 

John S. Kallal