Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Yuri Gribov
On Wed, Jul 19, 2017 at 8:19 PM, Alexander Monakov wrote: > On Wed, 19 Jul 2017, Yuri Gribov wrote: >> 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'

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Alexander Monakov
On Wed, 19 Jul 2017, Alexander Monakov wrote: > > 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. > > It's an inconvenience. People w

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Alexander Monakov
On Wed, 19 Jul 2017, Yuri Gribov wrote: > 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. No, it's not "my logic

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Yuri Gribov
On Wed, Jul 19, 2017 at 4:30 PM, Alexander Monakov 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 th

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Alexander Monakov
On Wed, 19 Jul 2017, Jakub Jelinek wrote: > > 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; > > Recognizing by name is IMNSHO unde

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Jakub Jelinek
On Wed, Jul 19, 2017 at 06:30:40PM +0300, Alexander Monakov 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 reas

Re: [PATCH v2] Add no_tail_call attribute

2017-07-19 Thread Alexander Monakov
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 functio

Re: [PATCH v2] Add no_tail_call attribute

2017-07-18 Thread Jeff Law
On 07/03/2017 12:08 PM, Yuri Gribov wrote: >>> 0001-Added-no_tail_call-attribute.patch >>> >>> >>> From 1f4590e7a633c6335512b012578bddba7602b3c9 Mon Sep 17 00:00:00 2001 >>> From: Yury Gribov >>> Date: Sun, 28 May 2017 21:02:20 +0100 >>> Subject: [PATCH] Added no_tail_call attribute. >>> >>> gcc/

Re: [PATCH v2] Add no_tail_call attribute

2017-07-03 Thread Yuri Gribov
On Mon, Jul 3, 2017 at 6:03 PM, Jeff Law wrote: > On 05/29/2017 11:24 PM, Yuri Gribov wrote: >> On Mon, May 29, 2017 at 8:14 AM, Yuri Gribov wrote: >>> Hi all, >>> >>> As discussed in >>> https://sourceware.org/ml/libc-alpha/2017-01/msg00455.html , some >>> libdl functions rely on return address

Re: [PATCH v2] Add no_tail_call attribute

2017-07-03 Thread Jeff Law
On 05/29/2017 11:24 PM, Yuri Gribov wrote: > On Mon, May 29, 2017 at 8:14 AM, Yuri Gribov wrote: >> Hi all, >> >> As discussed in >> https://sourceware.org/ml/libc-alpha/2017-01/msg00455.html , some >> libdl functions rely on return address to figure out the calling >> DSO and then use this inform

[PATCH v2] Add no_tail_call attribute

2017-05-29 Thread Yuri Gribov
On Mon, May 29, 2017 at 8:14 AM, Yuri Gribov wrote: > Hi all, > > As discussed in > https://sourceware.org/ml/libc-alpha/2017-01/msg00455.html , 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 > depend