Re: Time to expand "Program received signal" ?

[<Paul_Koning@Dell.com>]

On Nov 15, 2012, at 1:16 PM, Eli Zaretskii wrote:

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

That doesn't tell you.  While threaded programs will often be linked with a threading library, they don't need to be.  Given an OS where threading is a basic service (as in NetBSD and I believe Linux) an application can create threads simply by calling the appropriate system service.

For that matter, even if it uses pthreads that doesn't mean it is linked against a dynamic library with a recognizable name.  The pthreads code might be statically linked, so it isn't readily visible when you look at the program executable file.

	paul