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
next prev parent 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).