Time to expand "Program received signal" ?

[John Gilmore]

> >> John> GDB shouldn't mention threads at all, unless the program being debugged
> >> John> is multi-threaded.
> 
> But you didn't address the issue that you can't readily tell whether a program is multi-threaded.  It may have had multiple threads but it doesn't now, or it may have more later.  This may be true even though it's not linked to libpthread -- that library might not even exist on the OS in question, or it may be linked in static, or the program may simply call the kernel's "create me a thread" syscall.

This isn't rocket science.

If the program "used to" have multiple threads, and only has one now,
it should be treated as single-threaded -- until it creates another thread.

If GDB can't tell whether there's more than one thread, it has to
treat the program as single-threaded.

What does GDB do if the user sets "scheduler-locking on" and GDB isn't
sure whether the target has multiple threads?  In general, GDB should
not let itself get into a situation where it doesn't know whether
there are other threads, since in that state it will violate its own
specifications.  Just as GDB shouldn't ever print a bogus value for a
variable.  The user should be able to depend on anything GDB tells
them about the program.  If they have to debug GDB, or work around
well-known bugs in it that make it lie about the state of the program,
they can't trust what it tells them about their own program.

	John