Re: Time to expand "Program received signal" ?

[Pedro Alves <palves at redhat dot com>]

On 15-11-2012 18:16, Eli Zaretskii wrote:

>>> 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.
> 
> Doesn't GDB already know whether some threading library is linked into
> the program?  If it does, then it knows whether another thread is
> possible or not.

In some cases yes.  But in general, no.  Most importantly, it doesn't
in the case people could care the most, which is remote debugging (of
random bare metal targets and RTOSs).

>> 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.
> 
> Neither does "thread 1", AFAIU.

It does.  The number space of threads is the same for all inferiors.
There's only one thread 1.  That, would be a separate discussion...

> 
>> My previous paste hinted at it.
> 
> I must be blind or stupid, 

I know you're neither.  :-)

> because I don't see any hints as to how would a signal be announced in your example.

(gdb) info inferiors
  Num  Description       Executable
* 2    process 9943      /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break
  1    process 9939      /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break
(gdb) info threads
  Id   Target Id         Frame
* 2    process 9943 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89
  1    process 9939 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89
(gdb)

Thread 1 received signal SIGFOO
Thread 2 received signal SIGFOO

Those would be different inferiors.

> 
>> It makes no sense to me to have "thread apply all FOO" do nothing
>> for non-threaded inferiors.
> 
> No one said it should do nothing.  "Main thread" implies there _is_ a
> thread.

Yes, and my point is, if people have no problem in calling these special
cases single-threaded (where single implies more than zero), and if
as you say, there _is_ a thread, then the discussion we're having
of whether to say "Thread 1 received ..." is a bit silly.  Either we assume
non-threaded == single-threaded, and admit that in that case non-threaded
inferiors always have at least one thread, or we don't, and "thread apply
all " should not apply to non-threaded inferiors.  As you called it, it's a
matter of self-consistency.

> 
>> 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.
> 
> Who said that the main thread is necessarily thread 1?  You cannot
> count on that.

I can, for non-threaded inferiors, which was my example.  In that
case, you either count 0 threads, or 1 thread, depending on calling
it non-threaded, or single-threaded.  But you can't ever have thread
N>1 before the inferior becomes multi-threaded (say, loads a threading
library).

-- 
Pedro Alves