Re: Thread Support for remote debugging

[Quality Quorum <qqi@theworld.com>]

On Thu, 31 Jan 2002, Andrew Cagney wrote:

>
> >> No, he means "knowing whether GDB and GDB Server support doing remote
> >> debugging at all", as far as I can tell.
> >>
> >> We've covered this ground a couple times lately :)  Someone promised to
> >> contribute thread support and dropped off the face of the earth.  It's
> >> on my TODO list, but I don't anticipate getting to it any time soon.
> >> Etc.
>
>
> (I recall the discussion, from memory one of the problems was the paper
> trail).  Daniel, you might consider doing what I do with my TODO list -
> just shove it all into GDB's bug database as change-requests :-)
>
>
> > If you are talking about me, I had it done more than one year ago:
> > http://world.std.com/~qqi, see section about gdb.
>
>
> Daniel isn't.
>
>
> > The problem is that (1) redhat never said 'yes we want it' so it is
> > sitll based on 4.18, (2) there are a few issues which could be
> > resolved one way or anotehr an readhat never said 'we want it this way'.
>
>
> (GDB is owned by the FSF (not Red Hat) and it is assumed that GDB
> developers put the FSF's interests before their own.)
>
> GDB currently comes with:
>
> gdb/*-stub.c:
> 	These are primative stubs that can be run on embedded boards.
> 	They appear to be public domain.
>
> gdb/gdbserver:
> 	This lets you debug a native UNIX program on a remote machine.
> 	It is GPLed.  It is owned by the FSF.
> 	Within the embedded community I suspect it is a hot product
> 	since it lets the developer debug a UNIX application
> 	running on the embedded machine remotely.
>
> My understanding of rproxy was that it could be linked with third party
> libraries and provide a remote protocol interface to JTAG devices and
> the like.  I wasn't aware that it could be used to do remote debugging
> of native applications.
>
> As for making rproxy part of GDB, I'm certainly interested (I didn't
> know you were looking to do this).  Since gdbserver is both owned by the
> FSF and is GPL, I would need to ensure that its replacement is no less
> ``free''. Would you be willing to contribute rproxy to the FSF?
>

I was not talking about rproxy (BTW, it does not support threads), I
have replacement for remote.c and reference stub supporting threads on
RTEMS.

> Andrew
>

Thanks,

Aleksey