From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul_Woegerer@mentor.com (Woegerer, Paul) Date: Fri, 14 Feb 2014 12:54:17 +0100 Subject: [lttng-dev] RFC: Fix crash in dlerror() In-Reply-To: References: <52F55511.2080309@mentor.com> <52FCCCD2.9050302@mentor.com> <610029715.24333.1392300717731.JavaMail.zimbra@efficios.com> <1692042945.24342.1392301795996.JavaMail.zimbra@efficios.com> <1119459836.24348.1392302831554.JavaMail.zimbra@efficios.com> <52FCE732.9090508@mentor.com> <581364674.24417.1392309613306.JavaMail.zimbra@efficios.com> <52FCF7F5.9070908@mentor.com>, <934762932.24558.1392317539645.JavaMail.zimbra@efficios.com>, <52FD4AB0.4060203@mentor.com> Message-ID: <52FE03E9.80204@mentor.com> On 02/14/2014 11:30 AM, Alexander Monakov wrote: > On Thu, 13 Feb 2014, Stefan Seefeld wrote: >> Our compilation unit defines a bunch of functions with external linkage, >> which access cur_alloc. And since gcc has no way to rule out that the >> call to dlsym() will not cause any of these functions to be called, it >> mustn't make any assumptions about whether or not the first >> initialization of cur_alloc is redundant or not, and thus shouldn't >> elide it. > Stefan, LTTng developers, > > The problem here is that glibc declares dlsym() with __attribute__((leaf)) > (see the definition of __THROW in /usr/include/sys/cdefs.h and the difference > from __THROWNL). Presence of the attribute allows the compiler to assume that > no functions from the current compilation unit will be called from dlsym, and > thus there's no need to write back potentially escaping data. So the CMM_ACCESS_ONCE's I suggested would only be required if dlsym() would call back into the wrapper from another thread, right ? Thanks, Paul > > glibc used to have __THROW annotations on dlopen() as well, and they changed > it to __THROWNL (removing the "leaf" attribute) after it was pointed out that > dlopen will call constructors: > > https://sourceware.org/ml/libc-alpha/2013-08/msg00465.html > > Unfortunately when I pointed out that dlsym is not really "leaf" as well, my > argument was dismissed: > > https://sourceware.org/ml/libc-alpha/2013-09/msg00012.html > > Please consider filing a glibc bug or otherwise reopening that discussion. > > Hope that helps, > Alexander -- Paul Woegerer, SW Development Engineer Sourcery Analyzer Mentor Graphics, Embedded Software Division