From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6735 invoked by alias); 18 Mar 2014 16:54:19 -0000 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 Received: (qmail 6721 invoked by uid 89); 18 Mar 2014 16:54:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 16:54:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4D85A11661D; Tue, 18 Mar 2014 12:54:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id usqGEv5EccTq; Tue, 18 Mar 2014 12:54:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1C414116437; Tue, 18 Mar 2014 12:54:15 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 8BC30E08A0; Tue, 18 Mar 2014 09:54:13 -0700 (PDT) Date: Tue, 18 Mar 2014 16:54:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue Message-ID: <20140318165413.GE4282@adacore.com> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> <83pplja2h9.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83pplja2h9.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00421.txt.bz2 > > Another thought I had on your patch is that we might want to limit > > the warning to situation where the return code is not a permission > > denied. > > I'm not sure we should bother. After all, if the problem is real, we > will get an error further down the line, when we use the handle to > that thread to do something with it. > > IOW, I see no need to thrash the entire session because of something > that isn't fatal. I didn't mean to change the behavior - only hide the warning. In this case, if it is normal that we can't suspend the thread, then there is no point in warning (scaring) the user about it. I would only generate a warning if something abnormal that we should fix occured. > > It would also have been nice to double-check that the thread in > > question, when the error shows up, is indeed on a system thread > > unrelated to our program (Eg: the thread created when we try to > > interrupt the program with ctrl-c or ctrl-break). Not sure if > > there is a way to determine that, though. > > I never use Ctrl-C/Ctrl/BREAK during debugging. The threads that I > was talking about just appear out of thin air, when the debuggee hits > a breakpoint, for example. I think we've seen that as well, I was just citing this thread as an example, because that's a case where I know that an unrelated thread gets created. > There's no rush. My problem is solved, so I can wait patiently ;-) OK :-). but don't let me stop you. I think you have as good a handle as I do, and perhaps others will comment as well. I think the only part we need to look at before putting your patch in is analyzing its side-effects. It cannot be all that bad, since you've been running with the patch for quite a while, now. -- Joel