From: stefan_seefeld@mentor.com (Stefan Seefeld)
Subject: [lttng-dev] RFC: Fix crash in dlerror()
Date: Thu, 13 Feb 2014 17:44:00 -0500 [thread overview]
Message-ID: <52FD4AB0.4060203@mentor.com> (raw)
In-Reply-To: <A30AF42E15BD64459E202697468DFFA77E389F61@EU-MBX-04.mgc.mentorg.com>
On 02/13/2014 05:06 PM, Woegerer, Paul wrote:
> Let me put it this way ...
>
> If (hypothetically, just for the sake of the argument) we would have dlsym with the following signature:
>
> void *dlsym(void *handle, const char *symbol, void *dummy);
>
> instead of:
>
> void *dlsym(void *handle, const char *symbol);
>
> and we would call it with:
>
> af.calloc = dlsym(RTLD_NEXT, "calloc", &cur_alloc);
>
> then (because of the aliasing of cur_alloc (caused by &cur_alloc) the compiler would be forced to store the effects done on cur_alloc into memory prior to calling dlsym.
Paul, I'm not convinced.
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.
(The above is in fact quite a frequent idiom in C/C++ framework
libraries. Just imagine dlsym() being a call into a GUI (such as an
event loop), and the functions in this CU unit as callbacks.)
Stefan
--
Stefan Seefeld
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/
next prev parent reply other threads:[~2014-02-13 22:44 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 [this message]
2014-02-14 6:59 ` Woegerer, Paul
2014-02-14 10:30 ` Alexander Monakov
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=52FD4AB0.4060203@mentor.com \
--to=stefan_seefeld@mentor.com \
/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