Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Dimitry Andric]

On 21 Jun 2017, at 02:15, Ryan Stone  wrote:
> 
> On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric  wrote:
> 
>> Solution B is problematic because arm_neon.h uses stdint.h types
>> extensively.
>> 
> 
> If I manually modify the arm_neon.h file to instead say this, the problem
> is avoided and the kernel builds:
> 
> #ifdef _KERNEL
> #include 
> #else
> #include 
> #endif
> 
> Do you think that the llvm devs would be willing to take a change to
> NeonEmitter that does this on FreeBSD?
> 
> This may not be a complete solution, though, as googling seems to indicate
> that gcc also provides a arm_neon.h and it also #includes 

Indeed.  It seems this header is not really designed to be included from
kernel space.  It is probably easiest to provide a kernel wrapper for
stdint.h, maybe even just for arm.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Ryan Stone]

On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric  wrote:

> Solution B is problematic because arm_neon.h uses stdint.h types
> extensively.
>

If I manually modify the arm_neon.h file to instead say this, the problem
is avoided and the kernel builds:

#ifdef _KERNEL
#include 
#else
#include 
#endif

Do you think that the llvm devs would be willing to take a change to
NeonEmitter that does this on FreeBSD?

This may not be a complete solution, though, as googling seems to indicate
that gcc also provides a arm_neon.h and it also #includes 
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Mark Millard]

On 2017-Jun-18, at 11:57 PM, Dimitry Andric  wrote:

> On 19 Jun 2017, at 08:46, Mark Millard  wrote:
>> 
>> This is a variant of the wording in bugzilla 220125:
>> 
>> Unless buildworld (not just kernel-toolchain) is used before
>> buildkernel the result for arm64 is:
>> 
>> --- armv8_crypto_wrap.o ---
>> In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:
>> /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/arm_neon.h:31:10:
>> fatal error: 'stdint.h' file not found
> ...
>> A) kernel-toolchain needs to establish a stdint.h
>>  that would be found
>> vs.
>> B) arm_neon.h needs to avoid needing stdint.h
>>  (presumes armv8_crypto_wrap.c is correct to
>>   include arm_neon.h )

(B) variant: Possibly finding a distinct stdint.h
when there is no $(WORLDTMP} tied one to be found?
(Avoiding needing the specific stdint.h that is
used when buildworld is used first.) Look in some
new place as a last resort (extended search path
list)?

>> at least if the kernel-toolchain then buildkernel
>> sequence is to be supported for arm64.
> 
> Solution A is problematic because it then would require to install
> headers into ${WORLDTMP}.  This is what buildworld does.

Is there anyplace outside of $(WORLDTMP} where an alternate
stdint.h could be made to be found if the ${WORLDTMP} places
do not have one to find? (The include notation is currently
 .)

Might some place related to (using my example full path
just for illustration, showing post-subsitutions):

/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/

be allowed have its own "failover" stdint.h to find as a
last resort?

(I do not claim this is well thought out.)

> Solution B is problematic because arm_neon.h uses stdint.h types
> extensively.

The instance of the file name need not be from the usual
place when there is no $(WORLDTMP} tied stdint.h to find?
So a different stdint.h instead of no stdint.h ?

> Maybe the solution with the least amount of work is to provide a
> kernel-specific wrapper header with the stdint.h types.

With also avoiding the #include  that would
otherwise fail?

> Otherwise, just use buildworld before buildkernel.

For now buildworld first is what I'd do for arm64.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Dimitry Andric]

On 19 Jun 2017, at 08:46, Mark Millard  wrote:
> 
> This is a variant of the wording in bugzilla 220125:
> 
> Unless buildworld (not just kernel-toolchain) is used before
> buildkernel the result for arm64 is:
> 
> --- armv8_crypto_wrap.o ---
> In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:
> /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/arm_neon.h:31:10:
> fatal error: 'stdint.h' file not found
...
> A) kernel-toolchain needs to establish a stdint.h
>   that would be found
> vs.
> B) arm_neon.h needs to avoid needing stdint.h
>   (presumes armv8_crypto_wrap.c is correct to
>include arm_neon.h )
> 
> at least if the kernel-toolchain then buildkernel
> sequence is to be supported for arm64.

Solution A is problematic because it then would require to install
headers into ${WORLDTMP}.  This is what buildworld does.

Solution B is problematic because arm_neon.h uses stdint.h types
extensively.

Maybe the solution with the least amount of work is to provide a
kernel-specific wrapper header with the stdint.h types.

Otherwise, just use buildworld before buildkernel.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Mark Millard]

This is a variant of the wording in bugzilla 220125:

Unless buildworld (not just kernel-toolchain) is used before
buildkernel the result for arm64 is:

--- armv8_crypto_wrap.o ---
In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/arm_neon.h:31:10:
fatal error: 'stdint.h' file not found
#include 
 ^~
--- all_subdir_armv8crypto ---
*** [armv8_crypto_wrap.o] Error code 1

Doing a kernel-toolchain build establishes:

# ls -dlT /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/*
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:57 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/arpa
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:59 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/gssapi
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:57 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/protocols
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:58 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpc
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:58 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpcsvc
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:59 2017
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/xlocale

which excludes the following that a buildworld establishes
(shown from a different build):

# find /usr/obj/cortexA53_clang/ -name stdint.h -print | more
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/sys/stdint.h
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/c++/v1/stdint.h
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/c++/v1/tr1/stdint.h
/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/stdint.h

One of:

A) kernel-toolchain needs to establish a stdint.h
   that would be found
vs.
B) arm_neon.h needs to avoid needing stdint.h
   (presumes armv8_crypto_wrap.c is correct to
include arm_neon.h )

at least if the kernel-toolchain then buildkernel
sequence is to be supported for arm64.


===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"