This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Add no_tail_call attribute
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jeff Law <law at redhat dot com>
- Cc: Yuri Gribov <tetra2005 at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 19 Jul 2017 18:30:40 +0300 (MSK)
- Subject: Re: [PATCH v2] Add no_tail_call attribute
- Authentication-results: sourceware.org; auth=none
- References: <CAJOtW+7aPA1oOHF1c6raPPqpdh=SrWnpgo6QzEwPJ5ZDk4tFgQ@mail.gmail.com> <2da62c8c-f651-1cd8-6cba-9e605a322ac8@redhat.com> <CAJOtW+7sHPPz3tLHA09RAuPusSTNfZ=1vUXHfCsFnnNy4Ab_Dw@mail.gmail.com> <7fe43f40-591a-4671-058e-232216b6bd0b@redhat.com>
On Wed, 19 Jul 2017, Jeff Law wrote:
> > Glibc people were worried that attribute would be lost when taking a
> > pointer to function
> > (https://sourceware.org/ml/libc-alpha/2017-01/msg00482.html). I think
> > their reasoning was that return address is a shadow argument for
> > dlsym-like functions so this would cause a (most likely inadvertent)
> > ABI error.
> Fair enough, but does the right thing happen if the function's
> definition is decorated? Can you add a test for that in the testsuite?
How would passing pointers to dlsym via a 'void *' work after this patch?
Honestly, if the goal is to assist users of GCC (and not only Glibc users,
but also people compiling against Bionic/musl/BSD libcs, which probably
wouldn't adopt this attribute), may I suggest that a clearer course of
action would be to:
1) recognize dlsym by name and suppress tailcalls to it
this would solve >99% cases because calling dlsym by pointer would be rare,
and has the benefit of not requiring libc header changes;
and
2) if we really want to offer some generic solution, can we give the users
a way to suppress tailcalls via a builtin? That is, introduce
foo = __builtin_notailcall (func (args))
I think this would allow libc headers to do
#define dlsym(sym, mod) __builtin_notailcall (dlsym (sym, mod))
I'm sorry for bringing up objections late, but I really ask for alternatives
to be considered, and I can take a stab at implementing either of the above
if the general course is agreed upon.
Alexander