public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@cavium.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Cc: nd@arm.com
Subject: Re: [Patch][aarch64]  Use IFUNCs to enable LSE instructions in libatomic on aarch64
Date: Mon, 28 Aug 2017 18:40:00 -0000	[thread overview]
Message-ID: <1503944731.28672.134.camel@cavium.com> (raw)
In-Reply-To: <59A03627.4060106@arm.com>

On Fri, 2017-08-25 at 15:37 +0100, Szabolcs Nagy wrote:

> the use of ifunc in gcc target libraries was a mistake
> in my opinion, there are several known bugs in the ifunc
> design and uclibc/musl/bionic don't plan to support it.
> but at this point i dont have a better proposal for doing
> runtime selection of optimal atomics code.
> 
> however in this patch i don't see why would the ctor run
> before ifunc resolvers. how does this work on x86_64?
> (there the different 16byte atomics are not even compatible,
> so if ifunc resolvers in different dsos return different
> result because one ran before the ctor, another after then
> the runtime behaviour is broken. this can happen when one
> dso is bindnow so ifunc relocation is processed before
> ctors and another runs resolvers lazily or dlopened later..
> but i didnt test it just looks broken)

I am not sure I followed everything here.  My basic testing all
worked, init_cpu_revision got run when libatomic was loaded and
then the IFUNC resolver gets called after that when one of the IFUNC
atomic functions is called.  init_cpu_revision sets libat_have_lse
which, I assume, will not be used by any other libraries.  If other
libraries have IFUNCs they would have their own static constructors and
set their own variables to be checked by their own IFUNCs.  So I am
not sure how one DSO is going to break another DSO.

> note that aarch64 ifunc resolvers get hwcap as an argument
> so all this brokenness can be avoided (and if we want to
> disable hwcap flags then probably glibc should take care
> of that before passing hwcap to the ifunc resolver).

I looked at the IFUNC memcpy resolver in glibc and it does not look
like it gets hwcap as an argument.  When I preprocess everything I see:

void *__libc_memcpy_ifunc (void) __asm__ ("__libc_memcpy");
void *__libc_memcpy_ifunc (void)
{
  uint64_t __attribute__((unused)) midr = _dl_aarch64_cpu_features.midr_el1;
  *res = ** expression that looks at midr value and returns function pointer **;
  return res;
}
__asm__ (".type " "__libc_memcpy" ", %gnu_indirect_function");
extern __typeof (__libc_memcpy) memcpy __attribute__ ((alias ("__libc_memcpy")));


Steve Ellcey
sellcey@cavium.com

  reply	other threads:[~2017-08-28 18:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 20:44 Steve Ellcey
2017-08-07 20:46 ` Steve Ellcey
2017-08-25  4:56   ` Steve Ellcey
2017-08-25 16:43 ` Szabolcs Nagy
2017-08-28 18:40   ` Steve Ellcey [this message]
2017-08-29 11:42     ` Szabolcs Nagy
2017-08-30 18:39       ` Steve Ellcey
2017-08-31 18:55       ` Steve Ellcey
2017-09-27 20:35         ` Steve Ellcey
2017-09-28 11:31         ` Szabolcs Nagy
2017-09-29 20:29           ` Steve Ellcey
2017-10-02 14:38             ` Szabolcs Nagy
2017-10-03 18:57               ` Steve Ellcey
2017-10-24 18:17                 ` Steve Ellcey
2017-11-20 18:27                   ` Steve Ellcey
2017-11-20 18:29                     ` James Greenhalgh
2017-11-20 19:50                       ` Steve Ellcey
2017-11-21 17:36                         ` James Greenhalgh
2017-11-29  8:09                           ` Steve Ellcey
2017-12-05  0:51                             ` Steve Ellcey
2017-12-07  9:56             ` James Greenhalgh
2017-12-07 15:58               ` Steve Ellcey

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=1503944731.28672.134.camel@cavium.com \
    --to=sellcey@cavium.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    --cc=szabolcs.nagy@arm.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).