From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30997 invoked by alias); 14 Aug 2007 03:12:14 -0000 Received: (qmail 30710 invoked by uid 22791); 14 Aug 2007 03:12:10 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Aug 2007 03:12:07 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-53-103.inter.net.il [83.130.53.103]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id IPZ95030 (AUTH halo1); Tue, 14 Aug 2007 06:11:57 +0300 (IDT) Date: Tue, 14 Aug 2007 03:12:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <200708132113.l7DLDWEw021526@brahms.sibelius.xs4all.nl> (message from Mark Kettenis on Mon, 13 Aug 2007 23:13:32 +0200 (CEST)) Subject: Re: [rfc] Delay deletion of step-resume breakpoints Reply-to: Eli Zaretskii References: <20070813210326.GA24049@caradoc.them.org> <200708132113.l7DLDWEw021526@brahms.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00276.txt.bz2 > Date: Mon, 13 Aug 2007 23:13:32 +0200 (CEST) > From: Mark Kettenis > CC: gdb-patches@sourceware.org > > > /* NOTE: this will take care of any left-over step_resume breakpoints, > > - but not any user-specified thread-specific breakpoints. */ > > + but not any user-specified thread-specific breakpoints. We can not > > + delete the breakpoint straight-off, because the inferior might not > > + be stopped at the moment. */ > > Makes me suspect this is just a workaround for another bug, the bug > being that the inferior isn't properly stopped when this code gets > called. Actually, I think that's TRT to do in _all_ cases: we are scheduling a breakpoint delete the next time GDB is in a predictable state to do that. That's exactly analogous to what a Posix filesystem does when you delete a file: if some process has that file open, the file is scheduled to be deleted when its last handle is closed. So I think Daniel's patch makes good sense.