[Bug python/12967] event.inferior_thread does not exist inall-stop/sync mode

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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.