This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit
- From: Pedro Alves <palves at redhat dot com>
- To: Muhammad Waqas <mwaqas at codesourcery dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org, tromey at redhat dot com, ali_anwar at codesourcery dot com
- Date: Fri, 02 Aug 2013 10:45:02 +0100
- Subject: Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit
- References: <51F619CE dot 5040407 at codesourcery dot com> <51F633E5 dot 7000302 at codesourcery dot com> <51F65519 dot 2080806 at codesourcery dot com> <51F67992 dot 30704 at codesourcery dot com> <51F7967E dot 3060900 at codesourcery dot com> <51FA4D21 dot 4000309 at redhat dot com> <51FA5806 dot 7050505 at codesourcery dot 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