Re: Time to expand "Program received signal" ?

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Thu, 15 Nov 2012 18:27:23 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com,
>         gdb@sourceware.org
> 
> > 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).

That's just too bad.

> >> 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, and in addition I cannot even know which thread belongs to
what inferior.

> 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.

> >> 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.

> >> 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.  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.