Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit

[Pedro Alves <palves@redhat.com>]

On 08/01/2013 01:43 PM, Muhammad Waqas wrote:
>>> >> +			    || !target_thread_alive (tp->ptid)))
>>> >> +	if ( tp != NULL && (tp->state == THREAD_EXITED
>>> >> +			    || !target_thread_alive (tp->ptid)))
>> > Do we really need this target_thread_alive call?  It
>> > means we have extra remote traffic whenever we have a thread
>> > specific breakpoint in the list.  If the user (or GDB itself)
>> > hasn't refreshed the thread list, is there any harm in delaying
>> > deleting the breakpoint?
>> >
>> > But, I think I agree with Yao in that this doesn't look like
>> > the right way to do this.
>> >
>> > In fact, breakpoint_auto_delete is only called when the
>> > target reports some stop.  If you're trying to delete
>> > stale thread specific breakpoints, then you'd want to
>> > do that even if the target hasn't reported a stop, right?
>> >
>> > Say, in non-stop mode, w/ the remote target, if you have two
>> > threads, set a thread-specific break on thread 2, and while
>> > all threads are running free in busy loops, not reporting
>> > any event, keep doing "info threads", and "info break".  At some
>> > point thread #2 exits.  You can see that from "info threads".
>> > But "info break" will still show you the stale breakpoint...
> If breakpoint will be deleted when thread list is updated through
> user or GDB and also when info break command is executed
> by user, Will it work? What will you say about this technique?
> 

I wouldn't even consider special casing "info break".  Otherwise,
you end up considering whether to handle all sorts of breakpoint
manipulation commands, like "enable", "disable", etc., and what
to do if the thread is already gone.

Tie this to GDB's own lifetime of the inferior's threads.  If GDB
learns the thread is gone, remove the breakpoint.  Otherwise,
leave it there.  Whether to remove the breakpoint immediately,
or mark it as disp_del_at_next_stop (and hide it, say, set its
bp->num to 0) is another question.  You'll note that
clear_thread_inferior_resources does the latter.  (That's because
most of GDB's native targets can't touch memory of running processes.)

-- 
Pedro Alves