Support pthread_setname_np

[ramosian-glider]

Originally reported on Google Code with ID 244

The interceptor was disabled in asan in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=194711

due to:
 #define COMMON_INTERCEPTOR_SET_THREAD_NAME(ctx, name) SetThreadName(name)
+// Should be asanThreadRegistry().SetThreadNameByUserId(thread, name)
+// But asan does not remember UserId's for threads (pthread_t);
+// and remembers all ever existed threads, so the linear search by UserId
+// can be slow.

We need to fix the 2 issues and reenable the interceptor.

Reported by dvyukov@google.com on 2013-11-15 07:58:34

[ramosian-glider]

Reported by ramosian.glider on 2015-07-30 09:05:31

• Labels added: ProjectAddressSanitizer

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:56

[morehouse]

@dvyukov: This has been disabled for almost 5 years now. Do we still plan to re-enable it?

[dvyukov]

I don't know if we plan to re-enable it or not. I guess generally not, but this is a good candidate for the fixit.

[rdhafidh]

@dvyukov, please dont, or provide runtime dlopen (if possible) detection whether there is pthread_setname_np or not. I have been satisfied that the chromium code now uses the assumption of the prctl function in linux instead of pthread_setname_np and my own llvm clang toolchain with compiler-rt against master branch so that I can even build on old linux kernel 2.6.32 glibc 2.11 server. Thanks

[dvyukov]

@dvyukov, please dont, or provide runtime dlopen (if possible) detection whether there is pthread_setname_np or not.

don't we already provide runtime detection for all interceptors?

[rdhafidh]

Yes, I see but I'm still maintaining my own home grown some build fix against eglibc 2.11 though.

I don't know if we plan to re-enable it or not. I guess generally not, but this is a good candidate for the fixit.

I was just worried with your statement for possibilty to drop support in the near future.

[dvyukov]

Yes, I see but I'm still maintaining my own home grown some build fix against eglibc 2.11 though.

Is there any reason for this? What?

I was just worried with your statement for possibilty to drop support in the near future.

This issue is about adding support, not dropping it.