From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24800 invoked by alias); 18 Mar 2014 16:35:59 -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 24790 invoked by uid 89); 18 Mar 2014 16:35:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Mar 2014 16:35:56 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N2N00C004IL5700@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Tue, 18 Mar 2014 18:35:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2N00BA94RTP5A0@a-mtaout23.012.net.il>; Tue, 18 Mar 2014 18:35:54 +0200 (IST) Date: Tue, 18 Mar 2014 16:35:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <20140318161608.GD4282@adacore.com> To: Joel Brobecker Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pplja2h9.fsf@gnu.org> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00419.txt.bz2 > Date: Tue, 18 Mar 2014 09:16:08 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > Generally speaking, it seems to make sense to me that we would > mark as unsuspended threads that we cannot suspend. But one question > that rises from doing that is: how does the rest of GDB handle > this thread? In particular, does the thread show up in "info thread" > and is the user able to switch to that thread? etc? I can try finding out, but it's not easy: since I made that change, these situations became so much rarer that it's a challenge to bump into them. I'll see what I can do. > Certainly, if the current situation is to leave the user stranded, > the suggested approach cannot only be an improvement... Exactly. > 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. > 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 would have looked into that, but I don't have much time this week, and > might be equally busy the following 2 weeks, so I didn't want to delay > my answer any further. Overall, your patch looks very promising. > > Sorry I can't be anymore support for the moment. There's no rush. My problem is solved, so I can wait patiently ;-) Thanks.