Re: [RFC] Prevent tailcall optimizations of libdl functions

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jan 25, 2017 at 04:43:32PM +0100, Florian Weimer wrote:
> On 01/25/2017 04:41 PM, Szabolcs Nagy wrote:
> > On 25/01/17 15:40, Florian Weimer wrote:
> > > On 01/25/2017 04:38 PM, Szabolcs Nagy wrote:
> > > > On 25/01/17 15:32, Yuri Gribov wrote:
> > > > > FWIW it sounds like GCC attribute would be the most natural solution
> > > > > (and probably also useful in other contexts). I'll try to cook a patch
> > > > > for GCC if there are no objections.
> > > > 
> > > > note that even if dlsym is marked notailcall, with
> > > > 
> > > > p = dlsym;
> > > > ...
> > > > return p();
> > > > 
> > > > if the type of p does not carry the attributes of
> > > > dlsym then this can be a tailcall.
> > > 
> > > Yes, but dlsym would still see the address of the function containing the dlsym call, which is what we need to
> > > determine the relevant object.
> > 
> > how?
> 
> At worst, the return address points to the code which jumps to the address
> p.  This code is still in the object which calls dlsym.

That can be a tail call and you get exactly the same problem as with direct
calls to dlsym.  We can make no_tail_call attribute a function type
attribute (like e.g. warn_unused_result and various others), then
you can actually avoid tail calls even on indirect calls.
But if you just
  void (*p) (void *, const char *) = dlsym;
  asm ("" : "+r" (p));
  return p (handle, "foobar");
then it can still be tail called (as the optimizers can't turn
that into a direct call and the function pointer doesn't have that
attribute).  And you can run into stuff like PR71463 too.

	Jakub