[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627210931.GT23102@port70.net>
Date: Fri, 27 Jun 2014 23:09:31 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Andy Lutomirski <luto@...capital.net>,
linux-arm-kernel@...ts.infradead.org,
Kees Cook <keescook@...omium.org>
Subject: Re: Re: Thread pointer changes
* Russell King - ARM Linux <linux@....linux.org.uk> [2014-06-27 21:09:49 +0100]:
> As I said above, enabling CONFIG_KUSER_HELPERS is known to be an ABI
> break, and it's well documented as such. The future will be running
> systems without the kuser helpers because on ARMv6 and later, there's
> little point in having them. In fact, today almost all C libraries
> are built without needing the kuser helpers.
i thought the helpers in the kernel can avoid certain memory
barriers that the userspace has to do on armv6 for atomics
(and those barriers are deprecated on armv7 so i thought the
kuser page was better for portable binaries)
> Due to that, any ARMv5 or earlier CPU will always have the kuser helper
> page. ARMv6 and later may or may not have the kuser helper page, but
> there you're really building for a different ABI anyway (VFP-based) and
> you also know that you have the thread registers.
so is it expected that the libc makes no attempt to provide
portable binary interface for armv5 and armv6?
ie should musl treat those as different targets?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
