Re: Time to expand "Program received signal" ?

[Pedro Alves <palves at redhat dot com>]

On 15-11-2012 19:08, Eli Zaretskii wrote:
>> Date: Thu, 15 Nov 2012 18:27:23 +0000
>> From: Pedro Alves <palves@redhat.com>

>>>> 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.
> 
> Which is even worse: now I still cannot know which inferior got the
> signal, 

(It's not worse than "Program received signal", which tells you nothing.)
Ideally you should be able to.  I tend to think of it as a separate
problem.  We could say something like "Inferior I, thread T received signal".
"Thread I.T" is more compact, and more "standard", if it weren't for the
current flat numbering scheme.  If there's a good suggestion
(that is implementable and correct; just suppressing the thread
number when there's only a single thread in the inferior is not) to tweak
to output, I'll implement it.

> and in addition I cannot even know which thread belongs to
> what inferior.

Yes, that's a problem.  But it's a larger problem than this specific
"received signal" issue though.

> 
>> Thread 1 received signal SIGFOO
>> Thread 2 received signal SIGFOO
>>
>> Those would be different inferiors.
> 
> Or 2 threads from the same inferior getting thread-specific signals.

Sure, but the important point is that there's a unique identifier,
better than "Program".  And it seems to me that at least mentioning
"Thread N" when there's only one thread would still be desirable.

> 
>>>> 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.
> 
> It's not silly, because these are two different use cases.  In one use
> case, the _user_ types a thread-related command.  In the other, _GDB_
> talks about threads in the context of a single-threaded program.  The
> former case cannot possibly cause user confusion, because it was the
> user who mentioned threads in the first place.
> 
>> 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.
> 
> The OP's concern was about the UI, not about GDB's own internal
> consistency.

But I'm talking about UI!  "thread apply all" is a user command.
If you'd expect "thread apply all bt" to produce a backtrace on a
non-threaded inferior, wouldn't you say that's because there _is_ _a_
thread in the inferior?  And if so then that thread must have a number
the user can refer to?  And if so, what is the issue with always
consistently telling the user the thread that got the signal?
I can't honestly believe any real user would be confused by this.

> 
>>>> 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).
> 
> You are missing the point, I think.  Again, the issue is not how GDB
> does its internal bookkeeping of threads.  

I'm explaining that we can refer to the main thread of non-threaded
programs in the CLI, which is a UI.  That the way to do that, is to refer
to thread 1.  IOW, in the UI, the main thread of non-threaded programs
is thread 1.

> The issue is how to present
> that to the user of a single-threaded program who might be confused to
> hear anything about threads, because she didn't start any.

I don't believe any user would be confused.  If there's any little confusion
at all, it can't seriously go beyond: "What's this thread 1 GDB is
talking about?  I didn't start any!  - It's the main thread.  - Oh, makes
sense."

Oh well, I'm beginning to consider dropping the patch for now.

-- 
Pedro Alves