RE: Thread Support for remote debugging

RE: Thread Support for remote debugging

[Korbel, Michal]

I was use source for gdbserver based on GDB 5.0,
but I was add protocol support based on Quality Quorum source code
(multithread and zbreak packet support)
and move part of multithread support from GDB 5.0 core into gdbserver code.
There are some bugs, but looks and work quite good.
The most importent is: " we can start debug after all thread are created",
there are problems with adding or deleting thread in internal thread list.
----------------------------------------------------------------------------
----------
Michal Korbel - Software engineer
Intel Technology Poland Sp. z o.o.; ul. Slowackiego 173; 80-298 Gdansk
tel. +48 58 34-81-726; fax: +48 58 34-81-505; mobile:+48 603-203-142 
----------------------------------------------------------------------------
----------



-----Original Message-----
From: Dan Kegel [mailto:dank@kegel.com]
Sent: Friday, February 01, 2002 4:51 PM
To: Korbel, Michal
Cc: 'Michael Snyder'; Sarnath K - CTD, Chennai.; gdb@sources.redhat.com
Subject: Re: Thread Support for remote debugging


"Korbel, Michal" wrote:
> 
> GDB have remote thread support and works fine with remote multithread
> target,
> to work with this feature you need have GDBSERVER with remote thread
> support.
> In the middle of 2001 I was build own version GDBSERVER with remote thread
> support (x86-linux target only).
> GDB (this version only) have only one restriction, the connection to
remote
> target can by start only from console window, but after first breakpoints
we
> can use all GDB features with full mouse support.

Now I'm really confused.  What source did you use for gdbserver?

- Dan

Re: Thread Support for remote debugging

[Dan Kegel]

Cool.  Can you post a patch, or an archive of your sources?
I'd like to link to it from http://www.kegel.com/linux/gdbserver.html
- Dan

"Korbel, Michal" wrote:
> 
> I was use source for gdbserver based on GDB 5.0,
> but I was add protocol support based on Quality Quorum source code
> (multithread and zbreak packet support)
> and move part of multithread support from GDB 5.0 core into gdbserver code.
> There are some bugs, but looks and work quite good.
> The most importent is: " we can start debug after all thread are created",
> there are problems with adding or deleting thread in internal thread list.
> ----------------------------------------------------------------------------
> ----------
> Michal Korbel - Software engineer
> Intel Technology Poland Sp. z o.o.; ul. Slowackiego 173; 80-298 Gdansk
> tel. +48 58 34-81-726; fax: +48 58 34-81-505; mobile:+48 603-203-142
> ----------------------------------------------------------------------------
> ----------
> 
> -----Original Message-----
> From: Dan Kegel [mailto:dank@kegel.com]
> Sent: Friday, February 01, 2002 4:51 PM
> To: Korbel, Michal
> Cc: 'Michael Snyder'; Sarnath K - CTD, Chennai.; gdb@sources.redhat.com
> Subject: Re: Thread Support for remote debugging
> 
> "Korbel, Michal" wrote:
> >
> > GDB have remote thread support and works fine with remote multithread
> > target,
> > to work with this feature you need have GDBSERVER with remote thread
> > support.
> > In the middle of 2001 I was build own version GDBSERVER with remote thread
> > support (x86-linux target only).
> > GDB (this version only) have only one restriction, the connection to
> remote
> > target can by start only from console window, but after first breakpoints
> we
> > can use all GDB features with full mouse support.
> 
> Now I'm really confused.  What source did you use for gdbserver?
> 
> - Dan

Re: Thread Support for remote debugging

[Quality Quorum]

On Fri, 1 Feb 2002, Dan Kegel wrote:

> Cool.  Can you post a patch, or an archive of your sources?
> I'd like to link to it from http://www.kegel.com/linux/gdbserver.html
> - Dan
>
>
> "Korbel, Michal" wrote:
> >
> > I was use source for gdbserver based on GDB 5.0,
> > but I was add protocol support based on Quality Quorum source code
> > (multithread and zbreak packet support)
> > and move part of multithread support from GDB 5.0 core into gdbserver code.
> > There are some bugs, but looks and work quite good.
> > The most importent is: " we can start debug after all thread are created",
> > there are problems with adding or deleting thread in internal thread list.

Great to hear this, however, I would like to warn everybody  (as an
original developer) that there are some protocol issues to be fixed
still, before serous advance could be achieved.

There is also an issue of clearly formulating goals - in my view remote
debugging has to provide the same functionality as local one.

BTW, is it possible to set up mailing list to discuss this topic
specifically ?


Thanks,

Aleksey

Re: Thread Support for remote debugging

[Dan Kegel]

"Korbel, Michal" wrote:
> 
> GDB have remote thread support and works fine with remote multithread
> target,
> to work with this feature you need have GDBSERVER with remote thread
> support.
> In the middle of 2001 I was build own version GDBSERVER with remote thread
> support (x86-linux target only).
> GDB (this version only) have only one restriction, the connection to remote
> target can by start only from console window, but after first breakpoints we
> can use all GDB features with full mouse support.

Now I'm really confused.  What source did you use for gdbserver?

- Dan

RE: Thread Support for remote debugging

[Korbel, Michal]

GDB have remote thread support and works fine with remote multithread
target,
to work with this feature you need have GDBSERVER with remote thread
support.
In the middle of 2001 I was build own version GDBSERVER with remote thread
support (x86-linux target only).
GDB (this version only) have only one restriction, the connection to remote
target can by start only from console window, but after first breakpoints we
can use all GDB features with full mouse support.

----------------------------------------------------------------------------
----------
Michal Korbel - Software engineer
Intel Technology Poland Sp. z o.o.; ul. Slowackiego 173; 80-298 Gdansk
tel. +48 58 34-81-726; fax: +48 58 34-81-505; mobile:+48 603-203-142 
----------------------------------------------------------------------------
----------

-----Original Message-----
From: Michael Snyder [mailto:msnyder@redhat.com]
Sent: Thursday, January 31, 2002 9:41 PM
To: Sarnath K - CTD, Chennai.
Cc: gdb@sources.redhat.com
Subject: Re: Thread Support for remote debugging


"Sarnath K - CTD, Chennai." wrote:
> 
> Hi,
>  I have been browsing the mail archives for
> knowing the current state of thread support
> while doing remote debugging using GDB.
>  Although a lot of discussions have happened,
> I am not able to find the current state of work
> in that area.

By "knowing the current state of thread support",
do you mean finding out whether the remote target
supports thread debugging?  

If GDB sends the remote target a request that the
remote target does not support, there is a well-defined
way in which the remote target should respond (I believe
it is by sending an empty response).

>  I downloaded the latest GDB sources. It doesnt
> support thread commands during remote debugging.
> May I know what is the state of work in this area ?
> Is there any patch available for this ?

I don't understand.  GDB implements the remote protocol
for thread support.  There are queries defined for asking
the target for the current thread ID, changing the current
thread ID, asking for a list of "live" threads, asking 
whether a particular thread is alive...

Re: Thread Support for remote debugging

[Quality Quorum]

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

Re: Thread Support for remote debugging

[Quality Quorum]

On Thu, 31 Jan 2002, Daniel Jacobowitz wrote:

> On Thu, Jan 31, 2002 at 06:22:07PM -0500, Quality Quorum wrote:
> > If you are talking about me, I had it done more than one year ago:
> > http://world.std.com/~qqi, see section about gdb.
> >
> > 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'.
>
> Red Hat has nothing officially to do with this, besides the number of
> GDB maintainers they employ.
>
> As for the stub - if you want to contribute it, that's nice.  But it
> doesn't really address the question, since current GDBserver doesn't
> even have any RTEMS support as far as I know.

First, protocol has to be fixed, then gdb side implementation has to
be fixed, and only then stub porting from RTEMS to the gdbserver
environment will start to make some sense.

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

Thanks,

Aleksey

Re: Thread Support for remote debugging

[Andrew Cagney]

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

Andrew

Re: Thread Support for remote debugging

[Daniel Jacobowitz]

On Thu, Jan 31, 2002 at 06:22:07PM -0500, Quality Quorum wrote:
> If you are talking about me, I had it done more than one year ago:
> http://world.std.com/~qqi, see section about gdb.
> 
> 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'.

Red Hat has nothing officially to do with this, besides the number of
GDB maintainers they employ.

As for the stub - if you want to contribute it, that's nice.  But it
doesn't really address the question, since current GDBserver doesn't
even have any RTEMS support as far as I know.

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

Re: Thread Support for remote debugging

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 31, 2002 at 03:34:04PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > On Thu, Jan 31, 2002 at 12:40:34PM -0800, Michael Snyder wrote:
> > > > "Sarnath K - CTD, Chennai." wrote:
> > > > >
> > > > > Hi,
> > > > >  I have been browsing the mail archives for
> > > > > knowing the current state of thread support
> > > > > while doing remote debugging using GDB.
> > > > >  Although a lot of discussions have happened,
> > > > > I am not able to find the current state of work
> > > > > in that area.
> > > >
> > > > By "knowing the current state of thread support",
> > > > do you mean finding out whether the remote target
> > > > supports thread debugging?
> > >
> > > No, he means "knowing whether GDB and GDB Server support doing remote
> > > debugging at all", as far as I can tell.
> >
> > Yeah, but gdb always supports doing remote thread debugging,
> > so the question comes down to whether gdbserver (ie. the
> > remote target, as I said) supports thread debugging.
> >
> > > 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.
> >
> > I trust you mean in gdbserver.  The support for remote threads
> > is already in gdb.
> 
> Yes, that's what I meant.  Sorry.

Didn't mean to be condescending or anything.  I'm just anxious to 
avoid duplication of effort.  Several people have already added 
thread support to the remote protocol, I'd hate to see it done again... 
;-)

Re: Thread Support for remote debugging

[Daniel Jacobowitz]

On Thu, Jan 31, 2002 at 03:34:04PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Jan 31, 2002 at 12:40:34PM -0800, Michael Snyder wrote:
> > > "Sarnath K - CTD, Chennai." wrote:
> > > >
> > > > Hi,
> > > >  I have been browsing the mail archives for
> > > > knowing the current state of thread support
> > > > while doing remote debugging using GDB.
> > > >  Although a lot of discussions have happened,
> > > > I am not able to find the current state of work
> > > > in that area.
> > >
> > > By "knowing the current state of thread support",
> > > do you mean finding out whether the remote target
> > > supports thread debugging?
> > 
> > No, he means "knowing whether GDB and GDB Server support doing remote
> > debugging at all", as far as I can tell.
> 
> Yeah, but gdb always supports doing remote thread debugging, 
> so the question comes down to whether gdbserver (ie. the 
> remote target, as I said) supports thread debugging.
> 
> > 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.
> 
> I trust you mean in gdbserver.  The support for remote threads
> is already in gdb.

Yes, that's what I meant.  Sorry.

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

Re: Thread Support for remote debugging

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 31, 2002 at 12:40:34PM -0800, Michael Snyder wrote:
> > "Sarnath K - CTD, Chennai." wrote:
> > >
> > > Hi,
> > >  I have been browsing the mail archives for
> > > knowing the current state of thread support
> > > while doing remote debugging using GDB.
> > >  Although a lot of discussions have happened,
> > > I am not able to find the current state of work
> > > in that area.
> >
> > By "knowing the current state of thread support",
> > do you mean finding out whether the remote target
> > supports thread debugging?
> 
> No, he means "knowing whether GDB and GDB Server support doing remote
> debugging at all", as far as I can tell.

Yeah, but gdb always supports doing remote thread debugging, 
so the question comes down to whether gdbserver (ie. the 
remote target, as I said) supports thread debugging.

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

I trust you mean in gdbserver.  The support for remote threads
is already in gdb.

Re: Thread Support for remote debugging

[Quality Quorum]

On Thu, 31 Jan 2002, Daniel Jacobowitz wrote:

> On Thu, Jan 31, 2002 at 12:40:34PM -0800, Michael Snyder wrote:
> > "Sarnath K - CTD, Chennai." wrote:
> > >
> > > Hi,
> > >  I have been browsing the mail archives for
> > > knowing the current state of thread support
> > > while doing remote debugging using GDB.
> > >  Although a lot of discussions have happened,
> > > I am not able to find the current state of work
> > > in that area.
> >
> > By "knowing the current state of thread support",
> > do you mean finding out whether the remote target
> > supports thread debugging?
>
> 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.

If you are talking about me, I had it done more than one year ago:
http://world.std.com/~qqi, see section about gdb.

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

> Daniel Jacobowitz                           Carnegie Mellon University

Thanks,

Aleksey

Re: Thread Support for remote debugging

[Daniel Jacobowitz]

On Thu, Jan 31, 2002 at 12:40:34PM -0800, Michael Snyder wrote:
> "Sarnath K - CTD, Chennai." wrote:
> > 
> > Hi,
> >  I have been browsing the mail archives for
> > knowing the current state of thread support
> > while doing remote debugging using GDB.
> >  Although a lot of discussions have happened,
> > I am not able to find the current state of work
> > in that area.
> 
> By "knowing the current state of thread support",
> do you mean finding out whether the remote target
> supports thread debugging?  

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.

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

Re: Thread Support for remote debugging

[Michael Snyder]

"Sarnath K - CTD, Chennai." wrote:
> 
> Hi,
>  I have been browsing the mail archives for
> knowing the current state of thread support
> while doing remote debugging using GDB.
>  Although a lot of discussions have happened,
> I am not able to find the current state of work
> in that area.

By "knowing the current state of thread support",
do you mean finding out whether the remote target
supports thread debugging?  

If GDB sends the remote target a request that the
remote target does not support, there is a well-defined
way in which the remote target should respond (I believe
it is by sending an empty response).

>  I downloaded the latest GDB sources. It doesnt
> support thread commands during remote debugging.
> May I know what is the state of work in this area ?
> Is there any patch available for this ?

I don't understand.  GDB implements the remote protocol
for thread support.  There are queries defined for asking
the target for the current thread ID, changing the current
thread ID, asking for a list of "live" threads, asking 
whether a particular thread is alive...

RE: Thread Support for remote debugging

[Sarnath K - CTD, Chennai.]

Hi,
 I had downloaded the remote protocol
spec from "qqi". The spec was too good
and I was directly able to follow the
"gdbserver" code. Thanks.
  Why is it that the "thread support"
for "remote debugging" has long remained
as a paper issue ? What are the real hurdles
stopping the implementation? How long it would
take to add this support for an architecture, say
i386. 

I am quite new to GDB internals. I am currently 
reading the "gdbint" manual. 

 If any1 could throw light on the overall
architecture of GDB ( I know itz a sort of
overkill ) and issues involved in enabling
thread support, I would be grateful.

Thank you,
Sarnath

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Monday, January 21, 2002 7:37 PM
To: Sarnath K - CTD, Chennai.
Cc: gdb@sources.redhat.com
Subject: Re: Thread Support for remote debugging


On Mon, Jan 21, 2002 at 02:37:20PM +0530, Sarnath K - CTD, Chennai. wrote:
> Hi,
>  I have been browsing the mail archives for
> knowing the current state of thread support
> while doing remote debugging using GDB.
>  Although a lot of discussions have happened,
> I am not able to find the current state of work
> in that area.
>  I downloaded the latest GDB sources. It doesnt
> support thread commands during remote debugging.
> May I know what is the state of work in this area ?
> Is there any patch available for this ?

No, there isn't.

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

Re: Thread Support for remote debugging

[Andrew Cagney]

> 
> 
> I put together spec and reference implementation, see section
> on Remote GDB Protocol at http://world.std.com/~qqi, it is
> 4.18 based though.
> 
> I would like also to draw maintainer's attention to this
> work - it fixes quite a few problems existing in the mainline.
> 
> If there is a public interest I can integrate it with
> recent stuff.


It fell of the end of my queue :-(  You'll notice I've started trying to 
restructure the remote doco, restructuring/working on the protocol spec 
comes under.  From memory you've also got an assignment in place.

BTW, at the risk of sounding pedantic.  Can you please change your page 
to clarify that gdb.texinfo and remote.c together define the remote 
protocol.  You've posted a really good draft formal specification.

Andrew

Re: Thread Support for remote debugging

[Quality Quorum]

On Mon, 21 Jan 2002, Sarnath K - CTD, Chennai. wrote:

> Hi,
>  I have been browsing the mail archives for
> knowing the current state of thread support
> while doing remote debugging using GDB.
>  Although a lot of discussions have happened,
> I am not able to find the current state of work
> in that area.
>  I downloaded the latest GDB sources. It doesnt
> support thread commands during remote debugging.
> May I know what is the state of work in this area ?
> Is there any patch available for this ?


I put together spec and reference implementation, see section
on Remote GDB Protocol at http://world.std.com/~qqi, it is
4.18 based though.

I would like also to draw maintainer's attention to this
work - it fixes quite a few problems existing in the mainline.

If there is a public interest I can integrate it with
recent stuff.

>
> Thanks,
> Sarnath
>

Thanks,

Aleksey

Re: Thread Support for remote debugging

[Daniel Jacobowitz]

On Mon, Jan 21, 2002 at 02:37:20PM +0530, Sarnath K - CTD, Chennai. wrote:
> Hi,
>  I have been browsing the mail archives for
> knowing the current state of thread support
> while doing remote debugging using GDB.
>  Although a lot of discussions have happened,
> I am not able to find the current state of work
> in that area.
>  I downloaded the latest GDB sources. It doesnt
> support thread commands during remote debugging.
> May I know what is the state of work in this area ?
> Is there any patch available for this ?

No, there isn't.

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

Thread Support for remote debugging

[Sarnath K - CTD, Chennai.]

Hi,
 I have been browsing the mail archives for
knowing the current state of thread support
while doing remote debugging using GDB.
 Although a lot of discussions have happened,
I am not able to find the current state of work
in that area.
 I downloaded the latest GDB sources. It doesnt
support thread commands during remote debugging.
May I know what is the state of work in this area ?
Is there any patch available for this ?

Thanks,
Sarnath