This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix "PC register is not available" issue
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 18 Mar 2014 09:54:13 -0700
- Subject: Re: [PATCH] Fix "PC register is not available" issue
- Authentication-results: sourceware.org; auth=none
- References: <83txawa9wk dot fsf at gnu dot org> <20140318161608 dot GD4282 at adacore dot com> <83pplja2h9 dot fsf at gnu dot org>
> > 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