* [Bug dynamic-link/21050] Prevent tailcall optimizations of libdl functions
[not found] <bug-21050-131@http.sourceware.org/bugzilla/>
@ 2020-10-12 8:44 ` jay.krell at cornell dot edu
2020-10-12 15:25 ` bugdal at aerifal dot cx
2020-10-12 20:24 ` fw at deneb dot enyo.de
2 siblings, 0 replies; 3+ messages in thread
From: jay.krell at cornell dot edu @ 2020-10-12 8:44 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=21050
Jay <jay.krell at cornell dot edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jay.krell at cornell dot edu
--- Comment #2 from Jay <jay.krell at cornell dot edu> ---
It is an ABI break, but I like approx:
void* dlsym_internal(void* handle, const char* name, void* notail);
static inline void* dlsym(void* handle, const char* name)
{
char notail[1];
return dlsym_internal(handle, name, notail);
}
Gcc should probably get an attribute.
I've heard of this problem in other contexts.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug dynamic-link/21050] Prevent tailcall optimizations of libdl functions
[not found] <bug-21050-131@http.sourceware.org/bugzilla/>
2020-10-12 8:44 ` [Bug dynamic-link/21050] Prevent tailcall optimizations of libdl functions jay.krell at cornell dot edu
@ 2020-10-12 15:25 ` bugdal at aerifal dot cx
2020-10-12 20:24 ` fw at deneb dot enyo.de
2 siblings, 0 replies; 3+ messages in thread
From: bugdal at aerifal dot cx @ 2020-10-12 15:25 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=21050
--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
The suggestion in comment 2 is a spec violation; it has a static identifier
dlsym in place of the required extern one, and also breaks the identity of
function pointers (different pointer per translation unit). You have to use
function-like macros to do this kind of thing in a conforming way, and the
macro still does not cover the case where the caller undefines the macro or
directly calls the function via its address.
I believe the right solution is to deprecate the old constant value of
RTLD_NEXT and instead define RTLD_NEXT to expand to the address of a static
anchor object inside the translation unit. The dynamic linker can then use that
anchor object, rather than the return address, to identify the DSO from which
it was called. This also fixes a lot of other usage patterns, e.g. where
library A calls dlsym_wrapper(RTLD_NEXT, "foo") and dlsym_wrapper is defined in
library B.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug dynamic-link/21050] Prevent tailcall optimizations of libdl functions
[not found] <bug-21050-131@http.sourceware.org/bugzilla/>
2020-10-12 8:44 ` [Bug dynamic-link/21050] Prevent tailcall optimizations of libdl functions jay.krell at cornell dot edu
2020-10-12 15:25 ` bugdal at aerifal dot cx
@ 2020-10-12 20:24 ` fw at deneb dot enyo.de
2 siblings, 0 replies; 3+ messages in thread
From: fw at deneb dot enyo.de @ 2020-10-12 20:24 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=21050
Florian Weimer <fw at deneb dot enyo.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fw at deneb dot enyo.de
--- Comment #4 from Florian Weimer <fw at deneb dot enyo.de> ---
(In reply to Rich Felker from comment #3)
> I believe the right solution is to deprecate the old constant value of
> RTLD_NEXT and instead define RTLD_NEXT to expand to the address of a static
> anchor object inside the translation unit. The dynamic linker can then use
> that anchor object, rather than the return address, to identify the DSO from
> which it was called. This also fixes a lot of other usage patterns, e.g.
> where library A calls dlsym_wrapper(RTLD_NEXT, "foo") and dlsym_wrapper is
> defined in library B.
This also came up in the 2017 thread:
https://sourceware.org/pipermail/libc-alpha/2017-January/078377.html
To me it looks still the best way to solve this.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread