svn commit: r291937 - in head: lib/libc/aarch64/sys lib/libc/arm/sys sys/arm/arm sys/arm/include sys/arm64/arm64 sys/arm64/include sys/conf sys/kern

[Ian Lepore]

On Thu, 2015-12-24 at 20:00 +0200, Konstantin Belousov wrote:
> On Thu, Dec 24, 2015 at 08:40:42AM -0700, Ian Lepore wrote:
> > On Mon, 2015-12-07 at 12:20 +0000, Konstantin Belousov wrote:
> > > Author: kib
> > > Date: Mon Dec  7 12:20:26 2015
> > > New Revision: 291937
> > > URL: https://svnweb.freebsd.org/changeset/base/291937
> > > 
> > > Log:
> > >   Add support for usermode (vdso-like) gettimeofday(2) and
> > >   clock_gettime(2) on ARMv7 and ARMv8 systems which have
> > > architectural
> > >   generic timer hardware. It is similar how the RDTSC timer is
> > > used in
> > >   userspace on x86.
> > >   
> > >   Fix a permission problem where generic timer access from EL0
> > > (or
> > >   userspace on v7) was not properly initialized on APs.
> > >   
> > >   For ARMv7, mark the stack non-executable. The shared page is
> > > added for
> > >   all arms (including ARMv8 64bit), and the signal trampoline
> > > code is
> > >   moved to the page.
> > >   
> > >   Reviewed by:> 	> andrew
> > >   Discussed with:> 	> emaste, mmel
> > >   Sponsored by:> 	> The FreeBSD Foundation
> > >   Differential revision:> 	
> > > https://reviews.freebsd.org/D4209
> > 
> > I've just discovered this change breaks buildworld on armv4/5
> > systems. 
> >  Those systems don't have the counter hardware that can be read
> > from
> > userland (they don't have any common timer hardware at all, every
> > system is different).  Also, they don't support the 'mrrc'
> > instruction,
> > so the buildworld fails to compile libc.
> 
> I tested the change with make universe.  Is the armv5 world included
> into the make ?   If yes, there is something even more broken.
> 
> That said, the code in __vdso_gettime.c is unused om armv4/v5 since
> kernel
> never directs libc to use a fast timecounter.  The routines could be
> left
> undefined since they are declared weak, or the bodies could be
> stubbed out.
> Anyway, to test, I should be able to compile libc for the target.
> 
> And, BTW, what is exactly your error message ?
> 

Oh, I know what's likely at the heart of this... I'm using gcc 4.2.1
for arm v4/v5, because clang 3.7 is broken (works to crossbuild, but
fails to run native).  The mrrc instruction was introduced at arm arch
5E, I'll bet clang is defaulting to 5E and gcc defaults to 4.

This is what's in my make.conf for the build that failed:

WITH_GCC=yes
WITH_GNUCXX=yes
WITH_GCC_BOOTSTRAP=yes
WITHOUT_CLANG=yes
WITHOUT_CLANG_IS_CC=yes
WITHOUT_CLANG_BOOTSTRAP=yes

Yep, just confirmed it, switched back to clang 3.7 for crossbuild and
no errors.

-- Ian