* [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode
2011-07-06 19:34 [Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode jan.kratochvil at redhat dot com
@ 2011-07-06 19:40 ` jan.kratochvil at redhat dot com
2012-01-03 22:03 ` tromey at redhat dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jan.kratochvil at redhat dot com @ 2011-07-06 19:40 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12967
--- Comment #1 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-07-06 19:39:13 UTC ---
The testcase being referenced is the updated one - before it gets checked in:
Re: [patch] Support inferior events in python
http://sourceware.org/ml/gdb-patches/2011-07/msg00209.html
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode
2011-07-06 19:34 [Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode jan.kratochvil at redhat dot com
2011-07-06 19:40 ` [Bug python/12967] " jan.kratochvil at redhat dot com
@ 2012-01-03 22:03 ` tromey at redhat dot com
2012-01-30 18:24 ` palves at redhat dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: tromey at redhat dot com @ 2012-01-03 22:03 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12967
Tom Tromey <tromey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com
--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2012-01-03 22:03:22 UTC ---
The docs say that inferior_thread should exist but be None
in all-stop. So, I think the bug is that it doesn't exist.
I think this may conflate the "event thread" and the "stop set"
a bit too much. This is something we should address once
I/T sets are in.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode
2011-07-06 19:34 [Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode jan.kratochvil at redhat dot com
2011-07-06 19:40 ` [Bug python/12967] " jan.kratochvil at redhat dot com
2012-01-03 22:03 ` tromey at redhat dot com
@ 2012-01-30 18:24 ` palves at redhat dot com
2012-01-31 16:37 ` tromey at redhat dot com
2012-01-31 17:15 ` palves at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: palves at redhat dot com @ 2012-01-30 18:24 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12967
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #3 from Pedro Alves <palves at redhat dot com> 2012-01-30 18:22:56 UTC ---
> The docs say that inferior_thread should exist but be None
> in all-stop. So, I think the bug is that it doesn't exist.
Is there a reason things were done this way? It's awkward that
the event doesn't say which thread was the event thread in all-stop
mode. Can't we just change that?
Stop events are still thread specific in all-stop. It's just
that gdb suspends all the other non-event threads for you.
E.g., with MI, in all-stop we have:
*stopped,frame={addr="0x000000339e6ef451",func="clone",args=[],from="/lib64/libc.so.6"},thread-id="1",stopped-threads="all",core="3"
Where thread-id is the moral equivalent of event.inferior_thread.
stopped-threads="all" indicates that everything else was suspended
along.
In non-stop, we have:
*stopped,frame={addr="0x000000339e6ef451",func="clone",args=[],from="/lib64/libc.so.6"},thread-id="1",stopped-threads=["1"],core="3"
Even if the ThreadEvent doesn't learn about something like the stopped-threads
set, it'd still be useful to at least make it report the event thread.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode
2011-07-06 19:34 [Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode jan.kratochvil at redhat dot com
` (2 preceding siblings ...)
2012-01-30 18:24 ` palves at redhat dot com
@ 2012-01-31 16:37 ` tromey at redhat dot com
2012-01-31 17:15 ` palves at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: tromey at redhat dot com @ 2012-01-31 16:37 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12967
--- Comment #4 from Tom Tromey <tromey at redhat dot com> 2012-01-31 16:36:27 UTC ---
(In reply to comment #3)
> > The docs say that inferior_thread should exist but be None
> > in all-stop. So, I think the bug is that it doesn't exist.
>
> Is there a reason things were done this way? It's awkward that
> the event doesn't say which thread was the event thread in all-stop
> mode. Can't we just change that?
There is a (very mild) compatibility concern.
If that matters then we could do it by adding a new field.
I agree this would be more clean; right now I assume that the
event handler is supposed to know that the current thread is the
stopping thread (if that is even true).
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode
2011-07-06 19:34 [Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode jan.kratochvil at redhat dot com
` (3 preceding siblings ...)
2012-01-31 16:37 ` tromey at redhat dot com
@ 2012-01-31 17:15 ` palves at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: palves at redhat dot com @ 2012-01-31 17:15 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12967
--- Comment #5 from Pedro Alves <palves at redhat dot com> 2012-01-31 17:14:41 UTC ---
> right now I assume that the event handler is supposed to know that the current thread is the stopping thread (if that is even true).
If that's true, it doesn't seem to be documented. The handler could also know
that is true for non-stop. This makes it unnecessary and redundant to have
event.inferior_thread in the first place.
If we fixed event.inferior_thread, scripts that are working around this by
looking at the current thread will still work.
> /* thread events can either be thread specific or process wide. If gdb is
> running in non-stop mode then the event is thread specific, otherwise
> it is process wide.
This is really bogus. A process wide event is something like a process exit,
and is really orthogonal to all-stop/non-stop/itsets. :-(
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread