This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Thread Support for remote debugging
- From: Quality Quorum <qqi at theworld dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Michael Snyder <msnyder at redhat dot com>, "Sarnath K - CTD, Chennai." <k_sarnath at ctd dot hcltech dot com>, <gdb at sources dot redhat dot com>
- Date: Thu, 31 Jan 2002 22:44:04 -0500
- Subject: Re: Thread Support for remote debugging
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