GDB code reuse for gdbserver?

GDB code reuse for gdbserver?

[Paul Koning]

Gentlepeople,

I'm wondering about a different approach to gdbserver.

Right now gdbserver is a target side remote-protocol machine (server.c) plus a separately developed version of target debugging machinery.  The latter duplicates what's in the main gdb directory, but only for a small number of platforms, possibly with reduced functionality, etc.

Rather than develop things twice, would it make sense to view gdbserver as the target machinery of gdb, connected to the rest of gdb by a remote-protocol pipe?  What that would actually mean is that gdbserver/server.c would talk to gdb target_ops methods.  So gdbserver would consist of the protocol code specific to gdbserver, plus target code from main gdb, plus bits of infrastructure sufficient to support the above.

Does this make sense?  (In other words, would such an approach be welcomed?)

	paul

Re: GDB code reuse for gdbserver?

[Joel Brobecker]

> Does this make sense?  (In other words, would such an approach be
> welcomed?)

I think we talked about this a few weeks back.  The answer is a definite
yes.  What we should do, IMO, is have GDB depend on the gdbserver code.
That way, we can think of implementing a gdbserver as the first step
towards implementing a native GDB (or seen differently, if you have
implemented a native GDB, then you should have a gdbserver for free).
I think that Pedro also mentioned that the GNU/Linux nat support was now
better in gdbserver as well.

That being said, I don't see this as an obvious task. But I would
certainly welcome it.

-- 
Joel

Re: GDB code reuse for gdbserver?

[Michael Snyder]

Joel Brobecker wrote:
>> Does this make sense?  (In other words, would such an approach be
>> welcomed?)
> 
> I think we talked about this a few weeks back.  The answer is a definite
> yes.  What we should do, IMO, is have GDB depend on the gdbserver code.
> That way, we can think of implementing a gdbserver as the first step
> towards implementing a native GDB (or seen differently, if you have
> implemented a native GDB, then you should have a gdbserver for free).
> I think that Pedro also mentioned that the GNU/Linux nat support was now
> better in gdbserver as well.
> 
> That being said, I don't see this as an obvious task. But I would
> certainly welcome it.
> 


Topic for the BoF?

My sketchy memory suggests that there is an issue with licensing.
Is not gdbserver somehow less restrictively licensed than gdb?

Re: GDB code reuse for gdbserver?

[Paul Koning]

On Oct 7, 2010, at 2:50 PM, Michael Snyder wrote:

> Joel Brobecker wrote:
>>> Does this make sense?  (In other words, would such an approach be
>>> welcomed?)
>> I think we talked about this a few weeks back.  The answer is a definite
>> yes.  What we should do, IMO, is have GDB depend on the gdbserver code.
>> That way, we can think of implementing a gdbserver as the first step
>> towards implementing a native GDB (or seen differently, if you have
>> implemented a native GDB, then you should have a gdbserver for free).

Interesting.  I had thought of it as the other way around, mostly because gdb is far more complete than gdbserver.

>> I think that Pedro also mentioned that the GNU/Linux nat support was now
>> better in gdbserver as well.

I didn't realize that...

>> That being said, I don't see this as an obvious task. But I would
>> certainly welcome it.
> 
> 
> Topic for the BoF?

Unfortunately I can't be there.

My reason for poking at this is (for the moment) NetBSD, which isn't supported at all in gdbserver.  There are bits in the NetBSD stream but those are not complete (thread support is an issue).  And while I could do it the existing way, i.e., do the work twice, it seemed to make sense to do it once and cover both use cases.

> 
> My sketchy memory suggests that there is an issue with licensing.
> Is not gdbserver somehow less restrictively licensed than gdb?

It doesn't look that way; both have GPL 3 on them in the current rev.

	paul