| Summary: | event.inferior_thread does not exist in all-stop/sync mode | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Jan Kratochvil <jan> |
| Component: | python | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | pedro, pmuldoon, tromey |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | --- | ||
| Host: | x86_64-fedora15-linux-gnu | Target: | x86_64-fedora15-linux-gnu |
| Build: | Last reconfirmed: | ||
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 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. > 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.
(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). > 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. :-( |
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.