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

[Garrett Cooper]

> On Dec 24, 2015, at 10:00, Konstantin Belousov <kostikbel at gmail.com> 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 ?

It was an assembler error on stable/9 at least...