Re: Time to expand "Program received signal" ?

[Pedro Alves <palves@redhat.com>]

On 15-11-2012 16:59, Eli Zaretskii wrote:
>> Date: Thu, 15 Nov 2012 10:36:26 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: Mark Kettenis <mark.kettenis@xs4all.nl>, brobecker@adacore.com,        gdb@sourceware.org
>>
>>> GDB shouldn't mention
>>> threads at all, unless the program being debugged has more than a
>>> single thread.
>>
>> See?  If it has a single thread, GDB calls that thread "thread 1".
> 
> To propose a compromise: can we call the only thread "main thread"
> instead of "thread 1"?

Not really.  You can end up with one thread in the list, even after
the "main thread" having exited.

Then, if you have two inferiors, each of them is non-threaded, saying
"main thread" still doesn't tell you which of the inferiors got the
signal.  My previous paste hinted at it.

We could say "inferior N" instead, but it's just much simpler to always call
the single thread in single-threaded inferiors a thread, rather than
having to explain (and care for) the special case of non-threaded
vs single-threaded.  I'd very much dislike that inconsistency.  I wouldn't
even know how to distinguish the cases, since with remote debugging,
GDB has no clue on whether the other end is threaded or not.

Some other points:

It makes no sense to me to have "thread apply all FOO" do nothing
for non-threaded inferiors.

E.g., this allows things like "b foo thread 1" to refer to the
main "thread" of a non-threaded program, even if it becomes
threaded by a later dlopen.

Etc.

> 
>> GDB's model calls the unit of scheduling in the inferior that got
>> the signal "Thread N".  You can "thread N" to switch to it.
>>
>> (gdb) maint print target-stack
>> The current target stack is:
>>   - child (Unix child process)
>>   - exec (Local exec file)
>>   - None (None)
>> (gdb) info threads
>>   Id   Target Id         Frame
>> * 1    process 9939 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89
> 
> This just says that GDB's model is self-consistent.  Being consistent
> doesn't necessarily mean being correct ;-)

Nor wrong.  But self-consistent is certainly better than inconsistent.

-- 
Pedro Alves