[Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode

[Bug python/12967] New: event.inferior_thread does not exist in all-stop/sync mode

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12967

           Summary: event.inferior_thread does not exist in all-stop/sync
                    mode
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned@sourceware.org
        ReportedBy: jan.kratochvil@redhat.com
                CC: pmuldoon@redhat.com
              Host: x86_64-fedora15-linux-gnu
            Target: x86_64-fedora15-linux-gnu


When I remove
gdb_test_no_output "set non-stop on"
gdb_test_no_output "set target-async on"

from gdb.python/py-evsignal.exp and gdb.python/py-evthreads.exp they will FAIL
because

event type: stop
stop reason: signal
stop signal: SIGUSR1
thread num: 3
event type: stop
(gdb) PASS: gdb.python/py-evsignal.exp: thread 3 was signaled

->

event type: stop
stop reason: signal
stop signal: SIGUSR1
event type: stop
(gdb) FAIL: gdb.python/py-evsignal.exp: Signal Thread 3

that means that event.inferior_thread does not exist; because:
        if ( event.inferior_thread is not None) :
            print "thread num: %s" % (event.inferior_thread.num);

But I do not see why event.inferior_thread would not exist in all-stop/sync
mode, it should not be related.

-- 
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.

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

[jan.kratochvil at redhat dot com]

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.

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

[tromey at redhat dot com]

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.

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

[palves at redhat dot com]

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.

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

[tromey at redhat dot com]

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.

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

[palves at redhat dot com]

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.