Re: Time to expand "Program received signal" ?

[Eli Zaretskii <eliz@gnu.org>]

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

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.

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

> My previous paste hinted at it.

I must be blind or stupid, because I don't see any hints as to how
would a signal be announced in your example.

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

> 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.
> > This just says that GDB's model is self-consistent.  Being consistent
> > doesn't necessarily mean being correct ;-)
> 
> Nor wrong.

Of course.

> But self-consistent is certainly better than inconsistent.

We are in violent agreement on this one.