Re: [RFC] Prevent tailcall optimizations of libdl functions

[Rich Felker <bugdal at aerifal dot cx>]

On Wed, Jan 25, 2017 at 12:28:41PM +0100, Florian Weimer wrote:
> On 01/25/2017 09:12 AM, Yuri Gribov wrote:
> >Hi all,
> >
> >This is a ping on https://sourceware.org/bugzilla/show_bug.cgi?id=21050
> >
> >Some libdl functions rely on return address to figure out the calling
> >DSO and then use this information in computation (e.g. output of dlsym
> >depends on which library called it).
> >
> >As reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826 this
> >may break under tailcall optimization i.e. in cases like
> >
> >  return dlsym(...);
> >
> >Rich Felker suggested that adding new GCC attribute is a possible
> >solution.
> 
> Several functions have essentially the same issue, so this seems a
> reasonable approach.
> 
> >Another option would be to hack around dlsym to prevent
> >tailcall from happening e.g.
> >  #define dlsym(h, name) { volatile void *sym = dlsym(h, name); return
> >(void *)sym; }
> 
> I'm not convinced that this prevents a tail call in all cases.  I'd
> also caution against adding yet another mechanism to preserve the
> caller context.
> 
> If we cannot get the GCC attribute to work, we should move dlsym
> into libc_nonshared.a and use __dso_handle, like we do for other
> functions which require the caller context.  This is not the
> direction I want us to move in; I prefer __builtin_return_address
> because it is easier to maintain, but that has the problem with tail
> calls.

FWIW this technique is non-conforming, at least for any standard
functions it's used on, since it breaks pointer equality. A conforming
program can evaluate p1==p2, where p1=dlsym is assigned in one dso and
p2=dlsym is assigned in another, and must see equality on a conforming
implementation. As such I think this hack needs to be removed from
other functions like stat.

Rich