Thread exit & create events

Thread exit & create events

[Veenu Verma (AS/EAB)]

Hello

We are integrating GDB back end with DSF ( Debugger Services Framework )
in Eclipse. 
Found two stumbling blocks around thread exit/create events

1. Though GDB raises a thread exit event but -thread-list-ids command
still list the reported exited thread for quite some time.
There is a gap till I guess the thread completely exits. Only info
threads give the hint by using "Exiting"  in information. 
This is a problem for us as we are relying on events and thread-list-ids
commands to paint the GUI. 
Info threads is used sparingly from front end.
Can -thread-list-ids command take into account the exited threads ? Is
it difficult to achieve this in GDB ? 

2. GDB thread identifier is not speicified when a thread is created or
exited. Only system identifier is used.
Again thread-list-ids uses only gdb thread identifier. Hence, the
mismatch and the problem.
Since on HP-UX systems gdb thread identifier is shown, I'm guessing it
shouldn't be hard to do the same for Linux.
Is there a reason for not to have gdb identifier on linux or it's just
that it's not done yet.


Veenu Khanna Verma
Ericsson - PDU Packet Server Platform


Veenu Khanna Verma
+46 7 38 09 33 09 / +46 8 727 36 05
AS/EAB/FTI/GT TADE Design
Ericsson - PDU Packet Server Platform

Re: Thread exit & create events

[Mark Kettenis]

> Date: Fri, 24 Aug 2007 10:51:10 +0200
> From: "Veenu Verma (AS/EAB)" <veenu.verma@ericsson.com>
> 
> Hello
> 
> We are integrating GDB back end with DSF ( Debugger Services Framework )
> in Eclipse. 
> Found two stumbling blocks around thread exit/create events
> 
> 1. Though GDB raises a thread exit event but -thread-list-ids command
> still list the reported exited thread for quite some time.
> There is a gap till I guess the thread completely exits. Only info
> threads give the hint by using "Exiting"  in information. 
> This is a problem for us as we are relying on events and thread-list-ids
> commands to paint the GUI. 
> Info threads is used sparingly from front end.
> Can -thread-list-ids command take into account the exited threads ? Is
> it difficult to achieve this in GDB ? 

GDB will defenitely need to keep track of the thread ID until the
thread is fully gone.  I guess -thread-list-ids simply uses GDB's
internal thread list, so exiting thread show up.  And I guess there
are people that actually want this, because the thread almost
certainly will still show up if you look for it with the tools your
operating system provides.

I guess the basic issue here is at what level you want to do thread
debugging.  For debugging code that simply uses threads, you may want
to see the thread disappear if you call pthread_exit() (or whatever
function the threading library provides for terminating threads).  But
if you have joinable threads you may want to keep them visible until
another thread has called pthread_join().

If you're debugging the threads library itself, you almost certainly
want to keep the thread visible until it has actually completely
stopped executing code.

> 2. GDB thread identifier is not speicified when a thread is created or
> exited. Only system identifier is used.
> Again thread-list-ids uses only gdb thread identifier. Hence, the
> mismatch and the problem.
> Since on HP-UX systems gdb thread identifier is shown, I'm guessing it
> shouldn't be hard to do the same for Linux.
> Is there a reason for not to have gdb identifier on linux or it's just
> that it's not done yet.

HP-UX has a rather well thought out debugging interface for threads.
That interface includes the possibility to store a thread identifier
in the kernel whenever a thread is created, and the debugger can ask
for that identifier.  That makes it possible for GDB to always know
the thread identifier.

Linux doesn't have a very well thought out threads debugging
interface.  There is special threads debugging library that is
supposed to help GDB find out things like userland thread identifiers,
but there are several versions of that library out there and some of
them have serious bugs.  The workarounds we have for these bugs mean
that there always is a period of time where we are not completely sure
whether a thread is still alive or dead.  During that time the thread
doesn't really have a valid thread identifier so it doesn't get
displayed.  Something similar happens when creating a thread.  When
the underlying kernel thread is created GDB notices that, but it
cannot yet ask the thread debugging library for the thread identifier,
since the data structures describing the thread haven't been set up
yet completely.

Re: Thread exit & create events

[Daniel Jacobowitz]

On Fri, Aug 24, 2007 at 12:46:24PM +0200, Mark Kettenis wrote:
> > 2. GDB thread identifier is not speicified when a thread is created or
> > exited. Only system identifier is used.
> > Again thread-list-ids uses only gdb thread identifier. Hence, the
> > mismatch and the problem.
> > Since on HP-UX systems gdb thread identifier is shown, I'm guessing it
> > shouldn't be hard to do the same for Linux.
> > Is there a reason for not to have gdb identifier on linux or it's just
> > that it's not done yet.
> 
> HP-UX has a rather well thought out debugging interface for threads.
> That interface includes the possibility to store a thread identifier
> in the kernel whenever a thread is created, and the debugger can ask
> for that identifier.  That makes it possible for GDB to always know
> the thread identifier.

I think that's not the same question we were asked.  The GDB thread
identifier is just the small integer associated with the thread in
GDB's list.  We say [New thread Thread BIG-OS-THREAD-ID] instead of
[New thread 2] but you have to say "thread 2" at the GDB prompt to
select it.

There's no good reason for it that I know of.  I am not sure why this
would be any different on HP-UX unless they're looking at WDB instead
of GDB.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Thread exit & create events

[Veenu Verma (AS/EAB)]

>I am not sure why this would be any different on HP-UX unless they're
looking at WDB instead of GDB.

In GDB documentation it says
 
For example, on HP-UX, you see
[New thread 2 (system thread 26594)]

For example, on GNU/Linux, you might see
[New Thread 46912507313328 (LWP 25582)

Is it difficult to incorporate this small integer while reporting an
event in GDB ?

  

/ Veenu

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: Friday, August 24, 2007 2:01 PM
To: Mark Kettenis
Cc: Veenu Verma (AS/EAB); gdb@sourceware.org
Subject: Re: Thread exit & create events

On Fri, Aug 24, 2007 at 12:46:24PM +0200, Mark Kettenis wrote:
> > 2. GDB thread identifier is not speicified when a thread is created 
> > or exited. Only system identifier is used.
> > Again thread-list-ids uses only gdb thread identifier. Hence, the 
> > mismatch and the problem.
> > Since on HP-UX systems gdb thread identifier is shown, I'm guessing 
> > it shouldn't be hard to do the same for Linux.
> > Is there a reason for not to have gdb identifier on linux or it's 
> > just that it's not done yet.
> 
> HP-UX has a rather well thought out debugging interface for threads.
> That interface includes the possibility to store a thread identifier 
> in the kernel whenever a thread is created, and the debugger can ask 
> for that identifier.  That makes it possible for GDB to always know 
> the thread identifier.

I think that's not the same question we were asked.  The GDB thread
identifier is just the small integer associated with the thread in GDB's
list.  We say [New thread Thread BIG-OS-THREAD-ID] instead of [New
thread 2] but you have to say "thread 2" at the GDB prompt to select it.

There's no good reason for it that I know of.  I am not sure why this
would be any different on HP-UX unless they're looking at WDB instead of
GDB.

--
Daniel Jacobowitz
CodeSourcery

Re: Thread exit & create events

[Daniel Jacobowitz]

On Fri, Aug 24, 2007 at 02:13:07PM +0200, Veenu Verma (AS/EAB) wrote:
> >I am not sure why this would be any different on HP-UX unless they're
> looking at WDB instead of GDB.
> 
> In GDB documentation it says
>  
> For example, on HP-UX, you see
> [New thread 2 (system thread 26594)]
> 
> For example, on GNU/Linux, you might see
> [New Thread 46912507313328 (LWP 25582)

I suspect that 2 is the system identifier on HP-UX and this is not
necessarily the same small integer as GDB's.  I might be wrong though,
I have never worked with the HP-UX code.

> Is it difficult to incorporate this small integer while reporting an
> event in GDB ?

No, but how are you getting these events in the first place?  Are you
really parsing the ~"" console output?

I think you can find discussions of a real MI event for this sort of
thing in the archives somewhere.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Thread exit & create events

[Veenu Verma (AS/EAB)]

 
> No, but how are you getting these events in the first place?  Are you
really parsing the ~"" console output?

> I think you can find discussions of a real MI event for this sort of
thing in the archives somewhere.

Yes, we are parsing console output. 
What do you mean by a real MI event ? Searched archive for "MI events"
but didnt find anything related.

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: Friday, August 24, 2007 2:19 PM
To: Veenu Verma (AS/EAB)
Cc: Mark Kettenis; gdb@sourceware.org
Subject: Re: Thread exit & create events

On Fri, Aug 24, 2007 at 02:13:07PM +0200, Veenu Verma (AS/EAB) wrote:
> >I am not sure why this would be any different on HP-UX unless they're
> looking at WDB instead of GDB.
> 
> In GDB documentation it says
>  
> For example, on HP-UX, you see
> [New thread 2 (system thread 26594)]
> 
> For example, on GNU/Linux, you might see [New Thread 46912507313328 
> (LWP 25582)

I suspect that 2 is the system identifier on HP-UX and this is not
necessarily the same small integer as GDB's.  I might be wrong though, I
have never worked with the HP-UX code.

> Is it difficult to incorporate this small integer while reporting an 
> event in GDB ?

No, but how are you getting these events in the first place?  Are you
really parsing the ~"" console output?

I think you can find discussions of a real MI event for this sort of
thing in the archives somewhere.

--
Daniel Jacobowitz
CodeSourcery

Re: Thread exit & create events

[Daniel Jacobowitz]

On Fri, Aug 24, 2007 at 03:14:53PM +0200, Veenu Verma (AS/EAB) wrote:
>  
> > No, but how are you getting these events in the first place?  Are you
> really parsing the ~"" console output?
> 
> > I think you can find discussions of a real MI event for this sort of
> thing in the archives somewhere.
> 
> Yes, we are parsing console output. 
> What do you mean by a real MI event ? Searched archive for "MI events"
> but didnt find anything related.

For instance, http://sourceware.org/ml/gdb/2003-05/msg00088.html.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Thread exit & create events

[Jim Blandy]

"Veenu Verma (AS/EAB)" <veenu.verma@ericsson.com> writes:
>> No, but how are you getting these events in the first place?  Are you
> really parsing the ~"" console output?
>
>> I think you can find discussions of a real MI event for this sort of
> thing in the archives somewhere.
>
> Yes, we are parsing console output. 
> What do you mean by a real MI event ? Searched archive for "MI events"
> but didnt find anything related.

If you look at the grammar for GDB/MI in the GDB manual (under "GDB/MI
Output Syntax"), the MI protocol allows for asynchronous notification
output, which is marked by a '=':

`NOTIFY-ASYNC-OUTPUT ==>'
     `[ TOKEN ] "=" ASYNC-OUTPUT'

...

   * NOTIFY-ASYNC-OUTPUT contains supplementary information that the
     client should handle (e.g., a new breakpoint information).  All
     notify output is prefixed by `='.

What you should do is define a new ASYNC-CLASS, which is sent with
RESULTs that carry the thread identifiers you're interested in.