Re: [Fwd: TARGET_WAITKIND_THREAD_[CREATION || DELETION]]

[jtc@redback.com (J.T. Conklin)]

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
Michael> I want to add two new entries to the list of reasons why
Michael> target_wait may return (ie. why the target may have stopped).
Michael> 	THREAD_CREATION, and 
Micheal>        THREAD_DELETION.
Micheal>
Michael> These will allow GDB to perform any housekeeping it needs to
Michael> do to manage threads. 

Sounds good.

Longer term, it might be useful to shape the breakpoint/watchpoint/
catchpoint/signal mechanism into a more general 'eventpoint' scheme,
where all sorts of events can be managed.  Ideally, it would be
relatively easy to add events on a per-target basis.

Micheal> For instance, GDB may want to remove a step_resume breakpoint
Micheal> that was in use by the thread that has exited.

This is important.  Many systems use the address of the thread control
block (whatever it may be called) as the thread id.  Also new TCBs are
often allocated from a free pool of TCBs from threads that have exited.
In such systems, it is quite common for different threads to have the
same IDs. If a breakpoint is set in a thread that exits, unless it is 
removed at that time it will also be present in the new thread.

Michael> Comments?

Glad to see such discussion on the public list :-)

        --jtc
        
-- 
J.T. Conklin
RedBack Networks