Bug 12967 - event.inferior_thread does not exist in all-stop/sync mode
Summary: event.inferior_thread does not exist in all-stop/sync mode
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-06 19:34 IST by Jan Kratochvil
Modified: 2012-01-31 17:14 IST (History)
3 users (show)

See Also:
Host: x86_64-fedora15-linux-gnu
Target: x86_64-fedora15-linux-gnu
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2011-07-06 19:34:06 IST
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.
Comment 1 Jan Kratochvil 2011-07-06 19:39:13 IST
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
Comment 2 Tom Tromey 2012-01-03 22:03:22 IST
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.
Comment 3 Pedro Alves 2012-01-30 18:22:56 IST
> 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.
Comment 4 Tom Tromey 2012-01-31 16:36:27 IST
(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).
Comment 5 Pedro Alves 2012-01-31 17:14:41 IST
> 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.  :-(