[[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Mark Hatle]

amd64 optimization when using with mingw32 sometimes results in:

| ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
']' before '.' token
|  103 | #define encT enc_tables.T

and then all usages of encT fail as well.

Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
---
 recipes-support/libgcrypt/libgcrypt_%.bbappend | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-support/libgcrypt/libgcrypt_%.bbappend b/recipes-support/libgcrypt/libgcrypt_%.bbappend
index 50dca09..92242d0 100644
--- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
+++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
@@ -1,3 +1,4 @@
+EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
 
 # libcap does not support mingw32
 PACKAGECONFIG_remove_mingw32 = "capabilities"
-- 
2.17.1

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Adrian Bunk]

On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
> amd64 optimization when using with mingw32 sometimes results in:
> 
> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
> ']' before '.' token
> |  103 | #define encT enc_tables.T
>...

Please send a complete build log, this looks like a parallel build 
failure where some .c is compiled before some header it uses is
fully generated (or something similar).

> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
> @@ -1,3 +1,4 @@
> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
>...

I assume PARALLEL_MAKE = "" would also work instead?

cu
Adrian

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Mark Hatle]

On 2/25/20 12:36 PM, Adrian Bunk wrote:
> On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
>> amd64 optimization when using with mingw32 sometimes results in:
>>
>> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
>> ']' before '.' token
>> |  103 | #define encT enc_tables.T
>> ...
> 
> Please send a complete build log, this looks like a parallel build 
> failure where some .c is compiled before some header it uses is
> fully generated (or something similar).

I'll reply with a private email to where you can get a copy of the build directory.

>> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
>> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
>> @@ -1,3 +1,4 @@
>> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
>> ...
> 
> I assume PARALLEL_MAKE = "" would also work instead?

I tried this and it didn't appear to make a difference.  I only see the problem
when building for mingw32.

I've never seen any issues for any other SDK target.

--Mark

> cu
> Adrian
> 

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Joshua Watt]

On 2/25/20 1:32 PM, Mark Hatle wrote:
>
> On 2/25/20 12:36 PM, Adrian Bunk wrote:
>> On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
>>> amd64 optimization when using with mingw32 sometimes results in:
>>>
>>> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
>>> ']' before '.' token
>>> |  103 | #define encT enc_tables.T
>>> ...
>> Please send a complete build log, this looks like a parallel build
>> failure where some .c is compiled before some header it uses is
>> fully generated (or something similar).
> I'll reply with a private email to where you can get a copy of the build directory.
>
>>> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>> @@ -1,3 +1,4 @@
>>> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
>>> ...
>> I assume PARALLEL_MAKE = "" would also work instead?
> I tried this and it didn't appear to make a difference.  I only see the problem
> when building for mingw32.

Did we ever figure out what was causing this? It does appear to be some 
sort of race condition at the moment, and I'm surprised we haven't seen 
it on the autobuilder (we have pretty good test coverage for meta-mingw 
there).

>
> I've never seen any issues for any other SDK target.
>
> --Mark
>
>> cu
>> Adrian
>>

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Mark Hatle]

Note, this is still happening.  Using meta-mingw w/ gatesgarth to build, and
including libgcrypt I get the same failure.  The failure resolves with
"--disable-amd64-as-feature-detection".

Looking at the code, I don't really understand it, but there are some lines
after that which may be more indicative of the actual error:

../../libgcrypt-1.8.6/cipher/rijndael.c: In function 'do_encrypt':
../../libgcrypt-1.8.6/cipher/rijndael-tables.h:103:24: error: expected ']'
before '.' token
  103 | #define encT enc_tables.T
      |                        ^
../../libgcrypt-1.8.6/cipher/rijndael.c:775:20: note: in expansion of macro 'encT'
  775 |                   [encT] "r" (encT)
      |                    ^~~~
../../libgcrypt-1.8.6/cipher/rijndael.c:776:17: error: undefined named operand
'encT'
  776 |                 : "cc", "memory", "r8", "r9", "r10", "r11");
      |                 ^

I can't find any difference in generated content anywhere, only that the
function (.c) that is failing seems to have a comments it's loading something
for use w/ a SysV style function:

# else
  /* Call SystemV ABI function without storing non-volatile XMM registers,
   * as target function does not use vector instruction sets. */
  const void *key = ctx->keyschenc;
  uintptr_t rounds = ctx->rounds;  
  uintptr_t ret;
  asm volatile ("movq %[encT], %%r8\n\t"
                "callq *%[ret]\n\t"
                : [ret] "=a" (ret),
                  "+D" (key),
                  "+S" (bx),
                  "+d" (ax),
                  "+c" (rounds)
                : "0" (_gcry_aes_amd64_encrypt_block),

As far as my configuration (all gatesgarth):

conf/bblayers.conf:
BBLAYERS ?= " \
    /scratch2/mhatle/2021/sources/poky/meta \
    /scratch2/mhatle/2021/sources/poky/meta-poky \
    /scratch2/mhatle/2021/sources/meta-mingw \
    /scratch2/mhatle/2021/sources/poky/../meta-xilinx/meta-xilinx-bsp \
    /scratch2/mhatle/2021/sources/poky/../meta-xilinx-tools \
    /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-python \
    /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-oe \
"

DISTRO=nodistro MACHINE=zynqmp-generic SDKMACHINE=x86_64-mingw32 bitbake
nativesdk-libgcrypt

On 3/3/20 9:19 AM, Joshua Watt wrote:
> 
> On 2/25/20 1:32 PM, Mark Hatle wrote:
>>
>> On 2/25/20 12:36 PM, Adrian Bunk wrote:
>>> On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
>>>> amd64 optimization when using with mingw32 sometimes results in:
>>>>
>>>> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
>>>> ']' before '.' token
>>>> |  103 | #define encT enc_tables.T
>>>> ...
>>> Please send a complete build log, this looks like a parallel build
>>> failure where some .c is compiled before some header it uses is
>>> fully generated (or something similar).
>> I'll reply with a private email to where you can get a copy of the build directory.
>>
>>>> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>>> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>>> @@ -1,3 +1,4 @@
>>>> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
>>>> ...
>>> I assume PARALLEL_MAKE = "" would also work instead?
>> I tried this and it didn't appear to make a difference.  I only see the problem
>> when building for mingw32.
> 
> Did we ever figure out what was causing this? It does appear to be some 
> sort of race condition at the moment, and I'm surprised we haven't seen 
> it on the autobuilder (we have pretty good test coverage for meta-mingw 
> there).
> 
>>
>> I've never seen any issues for any other SDK target.
>>
>> --Mark
>>
>>> cu
>>> Adrian
>>>
>>>
>>> 

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Khem Raj]

On Wed, Dec 16, 2020 at 4:50 PM Mark Hatle
<mark.hatle@kernel.crashing.org> wrote:
>
> Note, this is still happening.  Using meta-mingw w/ gatesgarth to build, and
> including libgcrypt I get the same failure.  The failure resolves with
> "--disable-amd64-as-feature-detection".
>
> Looking at the code, I don't really understand it, but there are some lines
> after that which may be more indicative of the actual error:
>
> ../../libgcrypt-1.8.6/cipher/rijndael.c: In function 'do_encrypt':
> ../../libgcrypt-1.8.6/cipher/rijndael-tables.h:103:24: error: expected ']'
> before '.' token
>   103 | #define encT enc_tables.T
>       |                        ^
> ../../libgcrypt-1.8.6/cipher/rijndael.c:775:20: note: in expansion of macro 'encT'
>   775 |                   [encT] "r" (encT)
>       |                    ^~~~
> ../../libgcrypt-1.8.6/cipher/rijndael.c:776:17: error: undefined named operand
> 'encT'
>   776 |                 : "cc", "memory", "r8", "r9", "r10", "r11");
>       |                 ^
>

does it have --enable-optimization switch on ? if so then its probing
the build platform
for features and detects XMM registers and enables them but perhaps
does not account
for it not being a sysv ABI based platform for right ABI calling convention
may be asm code have made some assumptions here

> I can't find any difference in generated content anywhere, only that the
> function (.c) that is failing seems to have a comments it's loading something
> for use w/ a SysV style function:
>
> # else
>   /* Call SystemV ABI function without storing non-volatile XMM registers,
>    * as target function does not use vector instruction sets. */
>   const void *key = ctx->keyschenc;
>   uintptr_t rounds = ctx->rounds;
>   uintptr_t ret;
>   asm volatile ("movq %[encT], %%r8\n\t"
>                 "callq *%[ret]\n\t"
>                 : [ret] "=a" (ret),
>                   "+D" (key),
>                   "+S" (bx),
>                   "+d" (ax),
>                   "+c" (rounds)
>                 : "0" (_gcry_aes_amd64_encrypt_block),
>
> As far as my configuration (all gatesgarth):
>
> conf/bblayers.conf:
> BBLAYERS ?= " \
>     /scratch2/mhatle/2021/sources/poky/meta \
>     /scratch2/mhatle/2021/sources/poky/meta-poky \
>     /scratch2/mhatle/2021/sources/meta-mingw \
>     /scratch2/mhatle/2021/sources/poky/../meta-xilinx/meta-xilinx-bsp \
>     /scratch2/mhatle/2021/sources/poky/../meta-xilinx-tools \
>     /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-python \
>     /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-oe \
> "
>
> DISTRO=nodistro MACHINE=zynqmp-generic SDKMACHINE=x86_64-mingw32 bitbake
> nativesdk-libgcrypt
>
> On 3/3/20 9:19 AM, Joshua Watt wrote:
> >
> > On 2/25/20 1:32 PM, Mark Hatle wrote:
> >>
> >> On 2/25/20 12:36 PM, Adrian Bunk wrote:
> >>> On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
> >>>> amd64 optimization when using with mingw32 sometimes results in:
> >>>>
> >>>> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
> >>>> ']' before '.' token
> >>>> |  103 | #define encT enc_tables.T
> >>>> ...
> >>> Please send a complete build log, this looks like a parallel build
> >>> failure where some .c is compiled before some header it uses is
> >>> fully generated (or something similar).
> >> I'll reply with a private email to where you can get a copy of the build directory.
> >>
> >>>> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
> >>>> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
> >>>> @@ -1,3 +1,4 @@
> >>>> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
> >>>> ...
> >>> I assume PARALLEL_MAKE = "" would also work instead?
> >> I tried this and it didn't appear to make a difference.  I only see the problem
> >> when building for mingw32.
> >
> > Did we ever figure out what was causing this? It does appear to be some
> > sort of race condition at the moment, and I'm surprised we haven't seen
> > it on the autobuilder (we have pretty good test coverage for meta-mingw
> > there).
> >
> >>
> >> I've never seen any issues for any other SDK target.
> >>
> >> --Mark
> >>
> >>> cu
> >>> Adrian
> >>>
> >>>
> >>>
>
> 
>

Re: [yocto] [[meta-mingw][PATCH] libgcrypt: disable amd64 optimization

[Mark Hatle]

Looking at the config.log, I only see the standard Yocto Project (nativesdk)
paths, as well as: --disable-asm --without-capabilities

I'm building on 18.04.4 LTS, I think it's a fairly standard config, no
containers or anything like that.

Hardware is Intel Xeon Gold 6130 CPU.

Using my other build machine, an 18.04.03 LTS machine, hardware is Intel Xeon
E5-2697v2.

So two different, but similar environments I get exactly the same problem.  I'm
pretty sure the original patch I sent is still needed, and simply won't cause
any issues for environments where this is not reproducible.  Worst case it
disables optimizations, and libgcrypt may be slightly slower (if the
optimizations even worked.)

(if anyone wants to look, I can give you access to the second build machine
where it's easily reproducible.)

--Mark

On 12/17/20 10:17 AM, Khem Raj wrote:
> On Wed, Dec 16, 2020 at 4:50 PM Mark Hatle
> <mark.hatle@kernel.crashing.org> wrote:
>>
>> Note, this is still happening.  Using meta-mingw w/ gatesgarth to build, and
>> including libgcrypt I get the same failure.  The failure resolves with
>> "--disable-amd64-as-feature-detection".
>>
>> Looking at the code, I don't really understand it, but there are some lines
>> after that which may be more indicative of the actual error:
>>
>> ../../libgcrypt-1.8.6/cipher/rijndael.c: In function 'do_encrypt':
>> ../../libgcrypt-1.8.6/cipher/rijndael-tables.h:103:24: error: expected ']'
>> before '.' token
>>   103 | #define encT enc_tables.T
>>       |                        ^
>> ../../libgcrypt-1.8.6/cipher/rijndael.c:775:20: note: in expansion of macro 'encT'
>>   775 |                   [encT] "r" (encT)
>>       |                    ^~~~
>> ../../libgcrypt-1.8.6/cipher/rijndael.c:776:17: error: undefined named operand
>> 'encT'
>>   776 |                 : "cc", "memory", "r8", "r9", "r10", "r11");
>>       |                 ^
>>
> 
> does it have --enable-optimization switch on ? if so then its probing
> the build platform
> for features and detects XMM registers and enables them but perhaps
> does not account
> for it not being a sysv ABI based platform for right ABI calling convention
> may be asm code have made some assumptions here
> 
>> I can't find any difference in generated content anywhere, only that the
>> function (.c) that is failing seems to have a comments it's loading something
>> for use w/ a SysV style function:
>>
>> # else
>>   /* Call SystemV ABI function without storing non-volatile XMM registers,
>>    * as target function does not use vector instruction sets. */
>>   const void *key = ctx->keyschenc;
>>   uintptr_t rounds = ctx->rounds;
>>   uintptr_t ret;
>>   asm volatile ("movq %[encT], %%r8\n\t"
>>                 "callq *%[ret]\n\t"
>>                 : [ret] "=a" (ret),
>>                   "+D" (key),
>>                   "+S" (bx),
>>                   "+d" (ax),
>>                   "+c" (rounds)
>>                 : "0" (_gcry_aes_amd64_encrypt_block),
>>
>> As far as my configuration (all gatesgarth):
>>
>> conf/bblayers.conf:
>> BBLAYERS ?= " \
>>     /scratch2/mhatle/2021/sources/poky/meta \
>>     /scratch2/mhatle/2021/sources/poky/meta-poky \
>>     /scratch2/mhatle/2021/sources/meta-mingw \
>>     /scratch2/mhatle/2021/sources/poky/../meta-xilinx/meta-xilinx-bsp \
>>     /scratch2/mhatle/2021/sources/poky/../meta-xilinx-tools \
>>     /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-python \
>>     /scratch2/mhatle/2021/sources/poky/../meta-openembedded/meta-oe \
>> "
>>
>> DISTRO=nodistro MACHINE=zynqmp-generic SDKMACHINE=x86_64-mingw32 bitbake
>> nativesdk-libgcrypt
>>
>> On 3/3/20 9:19 AM, Joshua Watt wrote:
>>>
>>> On 2/25/20 1:32 PM, Mark Hatle wrote:
>>>>
>>>> On 2/25/20 12:36 PM, Adrian Bunk wrote:
>>>>> On Tue, Feb 25, 2020 at 12:02:14PM -0600, Mark Hatle wrote:
>>>>>> amd64 optimization when using with mingw32 sometimes results in:
>>>>>>
>>>>>> | ../../libgcrypt-1.8.4/cipher/rijndael-tables.h:103:24: error: expected
>>>>>> ']' before '.' token
>>>>>> |  103 | #define encT enc_tables.T
>>>>>> ...
>>>>> Please send a complete build log, this looks like a parallel build
>>>>> failure where some .c is compiled before some header it uses is
>>>>> fully generated (or something similar).
>>>> I'll reply with a private email to where you can get a copy of the build directory.
>>>>
>>>>>> --- a/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>>>>> +++ b/recipes-support/libgcrypt/libgcrypt_%.bbappend
>>>>>> @@ -1,3 +1,4 @@
>>>>>> +EXTRA_OECONF_append_mingw32 = " --disable-amd64-as-feature-detection"
>>>>>> ...
>>>>> I assume PARALLEL_MAKE = "" would also work instead?
>>>> I tried this and it didn't appear to make a difference.  I only see the problem
>>>> when building for mingw32.
>>>
>>> Did we ever figure out what was causing this? It does appear to be some
>>> sort of race condition at the moment, and I'm surprised we haven't seen
>>> it on the autobuilder (we have pretty good test coverage for meta-mingw
>>> there).
>>>
>>>>
>>>> I've never seen any issues for any other SDK target.
>>>>
>>>> --Mark
>>>>
>>>>> cu
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
>> 
>>