This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Time to expand "Program received signal" ?
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