public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Yuri Gribov <tetra2005@gmail.com>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Jeff Law <law@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>,
		Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH v2] Add no_tail_call attribute
Date: Wed, 19 Jul 2017 18:19:00 -0000	[thread overview]
Message-ID: <CAJOtW+4Eh58pKqZd6vjfvgZdq_2trvAStLxkdSnydegyj+dpLw@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.20.13.1707191821170.25203@monopod.intra.ispras.ru>

On Wed, Jul 19, 2017 at 4:30 PM, Alexander Monakov <amonakov@ispras.ru> wrote:
> 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?

Hi Alex,

Interesting, do people really do this sort of stuff?

So to reiterate, your logic here is that someone would wipe dlsym type
(e.g. by casting to void *), then later cast to another type which
lacks tailcall attribute. So proposed solution won't protect against
situation like this.

But isn't it similar to a situation when someone casts unaligned int *
(e.g. from a packed struct) to void * and then casts back to (aligned)
int *, expecting it to work (rather than SIGBUSing)?  If user dumps
important semantic attribute, it's his responsibility to properly
restore it before using the object.  In this particular case, he'd
need to cast void * to void (*)(void) __attribute__((notailcall));

> 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),

Could you give more details here - why would they have problems with
notailcall approach?

> 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;

I'm not sure how this is going to save above problem with casting to void *.

> 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))

Could be done but what is the advantage compared to attribute?  It
does not seem to fix issue you posted in the beginning.

The one and only advantage of attribute compared to Jakubs approach
(or yours, they share the same idea of wrapping dlsym calls) is that
it forces user to carry it around when taking address of function.

> 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.

It's totally fine to bring up objections as long as we clearly list
advantages and disadvantages of alternatives.

-Y

  parent reply	other threads:[~2017-07-19 18:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-30  5:59 Yuri Gribov
2017-07-03 17:03 ` Jeff Law
2017-07-03 18:08   ` Yuri Gribov
2017-07-19  6:00     ` Jeff Law
2017-07-19 15:31       ` Alexander Monakov
2017-07-19 15:36         ` Jakub Jelinek
2017-07-19 16:31           ` Alexander Monakov
2017-07-19 18:19         ` Yuri Gribov [this message]
2017-07-19 19:20           ` Alexander Monakov
2017-07-19 20:27             ` Alexander Monakov
2017-07-19 21:06             ` Yuri Gribov

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=CAJOtW+4Eh58pKqZd6vjfvgZdq_2trvAStLxkdSnydegyj+dpLw@mail.gmail.com \
    --to=tetra2005@gmail.com \
    --cc=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=law@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).