Re: Re: Thread pointer changes

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Fri, Jun 27, 2014 at 05:55:41PM -0400, Rich Felker wrote:
> I think you're assuming that libc is used only as a shared library and
> that the user installs one appropriate for their kernel. This
> precludes the use of static-linked binaries which are an extremely
> important usage case for us, especially on ARM where, for example, we
> want users to be able to make binaries that have a fully-working libc
> but that can be run on Android, where neither musl nor any other
> remotely-working libc is installed by default.
> 
> Obviously some (many) users will opt to build libc with a particular
> -march where all of the necessary instructions for TLS and atomics are
> available without help from the kernel. However, if attempting to
> build a baseline libc that works on any model results in one that
> can't work on new hardware/kernel, that's a big problem, and exactly
> the one which I'm trying to solve.

As I've already said, that's a system integrator bug to have a kernel
without a kuser page with userspace which requires it.

I think you're are missing one obvious solution to this which you can do:
you are passed the HWCAP fields in the ELF auxinfo.  This will tell you
if the CPU has TLS support or not.  If it has TLS support, then you don't
need to use the kuser helpers, and you know that it is a CPU which is ARM
architecture v6k or later, and it has things like the CP15 barrier
instructions.  If you want to know that the CPU supports the DMB
instruction rather than the CP15 barrier instruction, then you have to
check the uname details, or read /proc/cpuinfo (but I'd rather you
didn't.)

In addition, the HWCAP fields tell you about some of the other
instructions and FP options which are available to you, whether there's
integer division available, etc.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.