Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: amonakov@ispras.ru (Alexander Monakov)
Subject: [lttng-dev] RFC: Fix crash in dlerror()
Date: Fri, 14 Feb 2014 14:30:29 +0400 (MSK)	[thread overview]
Message-ID: <alpine.LNX.2.00.1402141420420.24828@monopod.intra.ispras.ru> (raw)
In-Reply-To: <52FD4AB0.4060203@mentor.com>

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.

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



  parent reply	other threads:[~2014-02-14 10:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 21:50 Stefan Seefeld
2014-02-08 16:06 ` Mathieu Desnoyers
2014-02-08 16:53   ` Stefan Seefeld
2014-02-08 22:22     ` Mathieu Desnoyers
2014-02-09 16:28       ` Stefan Seefeld
2014-02-11  0:31         ` Mathieu Desnoyers
2014-02-11  0:53       ` Stefan Seefeld
2014-02-11 20:51         ` Mathieu Desnoyers
2014-02-11 20:55           ` Stefan Seefeld
2014-02-12  3:39             ` Mathieu Desnoyers
2014-02-12 14:35               ` Mathieu Desnoyers
2014-02-12 21:59                 ` Mathieu Desnoyers
     [not found] ` <52FCAA28.6020708@mentor.com>
     [not found]   ` <1026072798.24303.1392297452496.JavaMail.zimbra@efficios.com>
     [not found]     ` <52FCCCD2.9050302@mentor.com>
     [not found]       ` <610029715.24333.1392300717731.JavaMail.zimbra@efficios.com>
     [not found]         ` <1692042945.24342.1392301795996.JavaMail.zimbra@efficios.com>
     [not found]           ` <1119459836.24348.1392302831554.JavaMail.zimbra@efficios.com>
     [not found]             ` <52FCE732.9090508@mentor.com>
2014-02-13 16:40               ` Mathieu Desnoyers
2014-02-13 16:51                 ` Woegerer, Paul
2014-02-13 18:52                   ` Mathieu Desnoyers
2014-02-13 19:44                     ` Woegerer, Paul
2014-02-13 22:06                       ` Woegerer, Paul
2014-02-13 22:44                         ` Stefan Seefeld
2014-02-14  6:59                           ` Woegerer, Paul
2014-02-14 10:30                           ` Alexander Monakov [this message]
2014-02-14 11:35                             ` Woegerer, Paul
2014-02-14 11:54                             ` Woegerer, Paul
2014-02-14 13:45                             ` [lttng-dev] [PATCH] Force static_alloc setup to be written into memory Paul Woegerer
2014-02-14 14:08                               ` Mathieu Desnoyers
2014-02-14 14:23                               ` Alexander Monakov
2014-02-14 14:39                                 ` Woegerer, Paul
2014-02-14 14:46                                 ` Stefan Seefeld
2014-02-14 15:12                                 ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.1402141420420.24828@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox