threadname support in KDevelop 4

Niko Sams niko.sams at
Sun Dec 20 12:57:03 UTC 2009

On Sun, Dec 20, 2009 at 09:35, Vladimir Prus <ghost at> wrote:
> On Friday 18 December 2009 03:23:46 Albert Zeyer wrote:
>> Hi,
>> I want to share some work/ideas/draft on threadname support in KDevelop 4.
>> The first idea which came to my mind was to throw a signal and write a custom
>> handler in KDevelop. This is by far not the nicest/cleanest way to do it but
>> it is simple. You could do something similar already at the GDB level and pass
>> the threadname over to KDevelop, which would be cleaner, but that would
>> already complicate things up.
>> Btw., this is also the same way MSVC is doing it. See the attached sample
>> code.
>> In this first demonstration, I tried to keep it as simple as possible. On
>> KDevelop, I will check for SIGUSR1 and search in the thread receiving this
>> signal for the first frame with a parameter called "name" and read that one.
>> This is the core function on the app side:
>> void setCurThreadName__signalraiser(const char* name) {
>>       // this signal is only for debuggers, we should ignore it
>>       signal( SIGUSR1, SIG_IGN );
>>       // KDevelop will catch this, read the 'name' parameter and continue execution
>>       raise( SIGUSR1 );
>> }
> As I have said on #gdb, this is somewhat hacky approach. For starters, the
> above code will break any application that uses SIGUSR1 for its own
> purposes already.
> For another thing, as soon you you expect that application need to follow
> a specific protocol to report the name of a thread, you can use a nicer
> protocol, e.g:
>        std::map<pthread_t, const char*> names;
>        void set_thread_name(const char *name)
>        { names[pthread_self()] = strdup (name); };
>    void thread_name(pthread_t t) { return names[t]; }

Imho this should be implemented on gdb side.
Vladimir, do you think this would be realistic?

Perhaps using python that finds out the names without the need for
this special function to the application?


More information about the KDevelop-devel mailing list