This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Disable thread specific breakpoints when thread dies
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: andrew dot stubbs at st dot com, gdb-patches at sources dot redhat dot com
- Date: Sat, 14 Jan 2006 10:45:53 -0500
- Subject: Re: [PATCH] Disable thread specific breakpoints when thread dies
- References: <20051113184515.GG3599@nevyn.them.org> <437875B0.4000007@st.com> <20051114155659.GA25717@nevyn.them.org> <437A19DE.6040905@st.com> <437B47A1.4040705@st.com> <20051117034811.GB3057@nevyn.them.org> <437CA66B.9060201@st.com> <20060112162659.GA16141@nevyn.them.org> <43C7E466.9080703@st.com> <200601132011.k0DKBZ8w006107@elgar.sibelius.xs4all.nl>
On Fri, Jan 13, 2006 at 09:11:35PM +0100, Mark Kettenis wrote:
> > Date: Fri, 13 Jan 2006 17:33:26 +0000
> > From: Andrew STUBBS <andrew.stubbs@st.com>
> >
> > Daniel Jacobowitz wrote:
> > >>> You shouldn't need to use the target method here. Does valid_thread_id
> > >>> work?
> > >>>
> > >>> Also, please remember the space before opening parentheses.
> > >> The thread still seems to have a valid ID after it has died. You can
> > >> even do 'b 8 t 4' after the program has exited. It does give an error
> > >> for threads which never existed though.
> > >
> > > Why does that happen? It is presumably a bug.
> > >
> >
> > I have looked into this. The problem is that the threads are only
> > deleted from the table when 'info threads' is used. The target method
> > works because that queries the target, not GDB's internal state, and
> > always gets the right answer (at least in our target interface).
At a guess, we should be calling whatever the appropriate function is
to empty the threads list in the generic bits of GDB, around where we
call the target mourn_inferior hook. Does that make sense?
> > I am happy, therefore, that the attached patch, with valid_thread_id(),
> > is correct, and will work once this other problem has been solved (or if
> > the user types 'info threads').
> >
> > OK to commit?
>
> Sorry, but I don't think we should commit a patch that's just papering
> over some other more serious problem, perhaps perhaps if there's some
> pressing need to do so.
Sorry about the confusion here - Mark, the patch Andrew posted is not a
workaround, but exactly the opposite. It's a correct patch that ought
to work, but doesn't because of a different bug, that he has
volunteered to track down next week.
With that clarified, do you have any objection to the patch?
--
Daniel Jacobowitz
CodeSourcery