[PATCH V3] meta: rust - Bug fix for target definitions returning 'NoneType' for arm


Sundeep KOKKONDA
 

The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append = " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_rust_gen_targets(d)
0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
0027:
0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
0029:python do_rust_gen_targets () {
0030: wd = d.getVar('WORKDIR') + '/targets/'
*** 0031: rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
0032: rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
0033: rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
0034:}
0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-common.inc', lineno: 330, function: rust_gen_target
0326: # build tspec
0327: tspec = {}
0328: tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
0329: tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
*** 0330: tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
0331: tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
0332: tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
0333: tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
0334: tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and aarch64 targets. Refer below, the tspec varibles for 'arm' generated with NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target for aarch64::
tspec['data-layout'] = aarch64-unknown-linux-gnu, Type of tspec['data-layout'] = <class 'str'>
tspec['max-atomic-width'] = 128, Type of tspec['max-atomic-width'] = <class 'int'>

Reason for changing arm-eabi to arm: The previous change introduced this bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@...>
---
meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):


## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"

## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
--
2.35.1


Sundeep KOKKONDA
 

Hello,

In which release this patch will be considered?


Richard Purdie
 

On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append = " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_rust_gen_targets(d)
0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
0027:
0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
0029:python do_rust_gen_targets () {
0030: wd = d.getVar('WORKDIR') + '/targets/'
*** 0031: rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
0032: rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
0033: rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
0034:}
0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-common.inc', lineno: 330, function: rust_gen_target
0326: # build tspec
0327: tspec = {}
0328: tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
0329: tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
*** 0330: tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
0331: tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
0332: tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
0333: tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
0334: tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and aarch64 targets. Refer below, the tspec varibles for 'arm' generated with NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target for aarch64::
tspec['data-layout'] = aarch64-unknown-linux-gnu, Type of tspec['data-layout'] = <class 'str'>
tspec['max-atomic-width'] = 128, Type of tspec['max-atomic-width'] = <class 'int'>

Reason for changing arm-eabi to arm: The previous change introduced this bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@...>
---
meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):


## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"

## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"

We've dropped this patch from testing. Why? It has been sent in a few different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.

The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.

As such I have no confidence this change is correct, tested or won't cause
future failures.

The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the sstate problem first, then we
can come back to this patch.

Cheers,

Richard


Sundeep KOKKONDA
 

Hello Richard,

On 19-04-2022 13:10, Richard Purdie wrote:
On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append = " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:do_rust_gen_targets(d)
     0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
     0027:
     0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
     0029:python do_rust_gen_targets () {
     0030:    wd = d.getVar('WORKDIR') + '/targets/'
 *** 0031:    rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
     0032:    rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
     0033:    rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
     0034:}
     0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-common.inc', lineno: 330, function: rust_gen_target
     0326:    # build tspec
     0327:    tspec = {}
     0328:    tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
     0329:    tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
 *** 0330:    tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
     0331:    tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
     0332:    tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
     0333:    tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
     0334:    tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and aarch64 targets. Refer below, the tspec varibles for 'arm' generated with NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  <class 'NoneType'>
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  <class 'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target  for aarch64::
tspec['data-layout'] =  aarch64-unknown-linux-gnu, Type of tspec['data-layout'] =  <class 'str'>
tspec['max-atomic-width'] =  128, Type of tspec['max-atomic-width'] =  <class 'int'>

Reason for changing arm-eabi to arm: The previous change introduced this bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@...>
---
 meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):
 
 
 ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
 
 ## armv7-unknown-linux-gnueabihf
 DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"

We've dropped this patch from testing. Why? It has been sent in a few different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.

The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.

As such I have no confidence this change is correct, tested or won't cause
future failures.

The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the sstate problem first, then we
can come back to this patch.

I analyzed the issue, the signature data of a Task is getting changed only when the Task is changed i.e., changes made 'within' the Task definition (in this case 'rust_gen_target' task). See the below sigdiff.

[skokkond@yow-fedora-builder1 buildA]$ bitbake-diffsigs tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.db412211fa29be71edbefb70b984c591b6818c3d238e29abf6c7a59f729fe13d ../buildB/tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.e56abb44c5d1544da8761ae0335e8c42faab6f61413ee7482c8a3797ae45d6b9
NOTE: Starting bitbake server...
basehash changed from 6a46ad5360b899c64cb2b3f9a9d41de2977d6b86e86d7fe2f25cb8d07bdeae15 to 7f93e436bb9f87ddcab0359945a3116faf6e9313ff4ae042fcb03d37925b1e92
Variable rust_gen_target value changed:
@@ -1,15 +1,18 @@
 def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""):
+    print("Inside rust_gen_target....")
     import json
     sys = sys_for(d, thing)
     prefix = prefix_for(d, thing)

     rust_arch = oe.rust.arch_to_rust_arch(arch)
+    print("rust_arch = ", rust_arch)

     if abi:
         arch_abi = "{}-{}".format(rust_arch, abi)
     else:
         arch_abi = rust_arch

+    print("arch_abi = ", arch_abi)
     features = features or d.getVarFlag('FEATURES', arch_abi) or ""
     features = features.strip()


Along with the above changes in 'rust_gen_target' task below changes are also present in the '/meta/recipes-devtools/rust/rust-common.inc' file. The below changes are definition of variables and these are not part of any Task definition. But the 'rust_gen_target' Task will use this data when it is building.

 ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"

The Yocto build system is not changing the signature of the Task when only these variable changes are present (w/o the changes in 'rust_gen_target' task definition).
In the current patch, there are no changes in the 'rust_gen_target' task definition and so the signature is not updated hence the 'rust_gen_target' task is not rebuilded.
I am not sure this behavior is a bug in Yocto or it is the expected behavior.
Also, in the build config the MACHINE set as "beaglebone-yocto", and I expected a change of signature in 'tmp/stamps/beaglebone_yocto-poky-linux-gnueabi/*' but the sigdata file changed in 'tmp/stamps/x86_64-linux/rust-native'. I am looking into it, but any clue here will be helpful.

Let me know if anything is not clear.


Thanks,

Sundeep K.


Cheers,

Richard






Richard Purdie
 

On Thu, 2022-05-05 at 16:41 +0530, Sundeep KOKKONDA wrote:
Hello Richard,

On 19-04-2022 13:10, Richard Purdie wrote:
 
On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
 
The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append
= " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error
executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:do_rust_gen_targets(d)
     0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
     0027:
     0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
     0029:python do_rust_gen_targets () {
     0030: wd = d.getVar('WORKDIR') + '/targets/'
 *** 0031: rust_gen_target(d, 'TARGET', wd,
d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'),
d.getVar('TARGET_ARCH'))
     0032: rust_gen_target(d, 'HOST', wd, "", "generic",
d.getVar('HOST_ARCH'))
     0033: rust_gen_target(d, 'BUILD', wd, "", "generic",
d.getVar('BUILD_ARCH'))
     0034:}
     0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
common.inc', lineno: 330, function: rust_gen_target
     0326: # build tspec
     0327: tspec = {}
     0328: tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
     0329: tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
 *** 0330: tspec['max-atomic-width'] =
int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
     0331: tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
     0332: tspec['target-c-int-width'] =
d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
     0333: tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN',
arch_abi)
     0334: tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and
aarch64 targets. Refer below, the tspec varibles for 'arm' generated with
NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class
'NoneType'>
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class
'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target for aarch64::
tspec['data-layout'] = aarch64-unknown-linux-gnu, Type of tspec['data-
layout'] = <class 'str'>
tspec['max-atomic-width'] = 128, Type of tspec['max-atomic-width'] =
<class 'int'>

Reason for changing arm-eabi to arm: The previous change introduced this
bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@...>
---
 meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-
devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):
 
 
 ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
 
 ## armv7-unknown-linux-gnueabihf
 DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
We've dropped this patch from testing. Why? It has been sent in a few
different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.

The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.

As such I have no confidence this change is correct, tested or won't cause
future failures.

The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the sstate problem first, then we
can come back to this patch.
I analyzed the issue, the signature data of a Task is getting changed only when
the Task is changed i.e., changes made 'within' the Task definition (in this
case 'rust_gen_target' task). See the below sigdiff.
 
 [skokkond@yow-fedora-builder1 buildA]$ bitbake-diffsigs tmp/stamps/x86_64-
linux/rust-native/1.60.0-
r0.do_rust_gen_targets.sigdata.db412211fa29be71edbefb70b984c591b6818c3d238e29abf
6c7a59f729fe13d ../buildB/tmp/stamps/x86_64-linux/rust-native/1.60.0-
r0.do_rust_gen_targets.sigdata.e56abb44c5d1544da8761ae0335e8c42faab6f61413ee7482
c8a3797ae45d6b9
NOTE: Starting bitbake server...
basehash changed from
6a46ad5360b899c64cb2b3f9a9d41de2977d6b86e86d7fe2f25cb8d07bdeae15 to
7f93e436bb9f87ddcab0359945a3116faf6e9313ff4ae042fcb03d37925b1e92
Variable rust_gen_target value changed:
@@ -1,15 +1,18 @@
 def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""):
+    print("Inside rust_gen_target....")
     import json
     sys = sys_for(d, thing)
     prefix = prefix_for(d, thing)

     rust_arch = oe.rust.arch_to_rust_arch(arch)
+    print("rust_arch = ", rust_arch)

     if abi:
         arch_abi = "{}-{}".format(rust_arch, abi)
     else:
         arch_abi = rust_arch

+    print("arch_abi = ", arch_abi)
     features = features or d.getVarFlag('FEATURES', arch_abi) or ""
     features = features.strip()
 
 
 Along with the above changes in 'rust_gen_target' task below changes are also
present in the '/meta/recipes-devtools/rust/rust-common.inc' file. The below
changes are definition of variables and these are not part of any Task
definition. But the 'rust_gen_target' Task will use this data when it is
building.
 
  ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
This suggests that the bitbake dependency parsing code can't track what that
function is doing and the dependencies need to be added manually. We probably
need something like:

rust_gen_target[vardeps] += "LLVM_TARGET"

but listing the various variables involved here.

 The Yocto build system is not changing the signature of the Task when only
these variable changes are present (w/o the changes in 'rust_gen_target' task
definition).
 In the current patch, there are no changes in the 'rust_gen_target' task
definition and so the signature is not updated hence the 'rust_gen_target' task
is not rebuilded.
 I am not sure this behavior is a bug in Yocto or it is the expected behavior.
 Also, in the build config the MACHINE set as "beaglebone-yocto", and I expected
a change of signature in 'tmp/stamps/beaglebone_yocto-poky-linux-gnueabi/*' but
the sigdata file changed in 'tmp/stamps/x86_64-linux/rust-native'. I am looking
into it, but any clue here will be helpful.
That sounds like a bug and I'd have expected one of the oe-selftests to find
that. It might be that we need a "native" comparision test similar to those in
test_sstate_allarch_samesigs

(run as "oe-selftest -r test_sstate_allarch_samesigs")

Cheers,

Richard


Sundeep KOKKONDA
 

Hello Richard,

On 05/05/22 19:02, Richard Purdie wrote:
On Thu, 2022-05-05 at 16:41 +0530, Sundeep KOKKONDA wrote:
Hello Richard,

On 19-04-2022 13:10, Richard Purdie wrote:
 
On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
 
The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append
= " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error
executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:do_rust_gen_targets(d)
     0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
     0027:
     0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
     0029:python do_rust_gen_targets () {
     0030:    wd = d.getVar('WORKDIR') + '/targets/'
 *** 0031:    rust_gen_target(d, 'TARGET', wd,
d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'),
d.getVar('TARGET_ARCH'))
     0032:    rust_gen_target(d, 'HOST', wd, "", "generic",
d.getVar('HOST_ARCH'))
     0033:    rust_gen_target(d, 'BUILD', wd, "", "generic",
d.getVar('BUILD_ARCH'))
     0034:}
     0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
common.inc', lineno: 330, function: rust_gen_target
     0326:    # build tspec
     0327:    tspec = {}
     0328:    tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
     0329:    tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
 *** 0330:    tspec['max-atomic-width'] =
int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
     0331:    tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
     0332:    tspec['target-c-int-width'] =
d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
     0333:    tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN',
arch_abi)
     0334:    tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and
aarch64 targets. Refer below, the tspec varibles for 'arm' generated with
NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  <class
'NoneType'>
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  <class
'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target  for aarch64::
tspec['data-layout'] =  aarch64-unknown-linux-gnu, Type of tspec['data-
layout'] =  <class 'str'>
tspec['max-atomic-width'] =  128, Type of tspec['max-atomic-width'] = 
<class 'int'>

Reason for changing arm-eabi to arm: The previous change introduced this
bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@...>
---
 meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-
devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):
 
 
 ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
 
 ## armv7-unknown-linux-gnueabihf
 DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
We've dropped this patch from testing. Why? It has been sent in a few
different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.

The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.

As such I have no confidence this change is correct, tested or won't cause
future failures.

The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the sstate problem first, then we
can come back to this patch.
I analyzed the issue, the signature data of a Task is getting changed only when
the Task is changed i.e., changes made 'within' the Task definition (in this
case 'rust_gen_target' task). See the below sigdiff.
 
 [skokkond@yow-fedora-builder1 buildA]$ bitbake-diffsigs tmp/stamps/x86_64-
linux/rust-native/1.60.0-
r0.do_rust_gen_targets.sigdata.db412211fa29be71edbefb70b984c591b6818c3d238e29abf
6c7a59f729fe13d ../buildB/tmp/stamps/x86_64-linux/rust-native/1.60.0-
r0.do_rust_gen_targets.sigdata.e56abb44c5d1544da8761ae0335e8c42faab6f61413ee7482
c8a3797ae45d6b9
NOTE: Starting bitbake server...
basehash changed from
6a46ad5360b899c64cb2b3f9a9d41de2977d6b86e86d7fe2f25cb8d07bdeae15 to
7f93e436bb9f87ddcab0359945a3116faf6e9313ff4ae042fcb03d37925b1e92
Variable rust_gen_target value changed:
@@ -1,15 +1,18 @@
 def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""):
+    print("Inside rust_gen_target....")
     import json
     sys = sys_for(d, thing)
     prefix = prefix_for(d, thing)

     rust_arch = oe.rust.arch_to_rust_arch(arch)
+    print("rust_arch = ", rust_arch)

     if abi:
         arch_abi = "{}-{}".format(rust_arch, abi)
     else:
         arch_abi = rust_arch

+    print("arch_abi = ", arch_abi)
     features = features or d.getVarFlag('FEATURES', arch_abi) or ""
     features = features.strip()
 
 
 Along with the above changes in 'rust_gen_target' task below changes are also
present in the '/meta/recipes-devtools/rust/rust-common.inc' file. The below
changes are definition of variables and these are not part of any Task
definition. But the 'rust_gen_target' Task will use this data when it is
building.
 
  ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"

This suggests that the bitbake dependency parsing code can't track what that
function is doing and the dependencies need to be added manually. We probably
need something like:

rust_gen_target[vardeps] += "LLVM_TARGET"

but listing the various variables involved here.
The below dependencies are added and then the sigdata is changed.

+do_rust_gen_targets[vardeps] += "DATA_LAYOUT"
+do_rust_gen_targets[vardeps] += "LLVM_TARGET"
+do_rust_gen_targets[vardeps] += "TARGET_ENDIAN"
+do_rust_gen_targets[vardeps] += "TARGET_POINTER_WIDTH"
+do_rust_gen_targets[vardeps] += "TARGET_C_INT_WIDTH"
+do_rust_gen_targets[vardeps] += "MAX_ATOMIC_WIDTH"
+do_rust_gen_targets[vardeps] += "FEATURES"

Below is the bitbake-diffsigs log snippet (Full log is attached - Refer attached diffsigs.txt)

[skokkond@yow-fedora-builder1 buildA]$ bitbake-diffsigs tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.db412211fa29be71edbefb70b984c591b6818c3d238e29abf6c7a59f729fe13d ../buildC/tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.e53213b3096706d321919f8716f2fcbcf1e954437ce09d7da09b4a2164cbc08e
NOTE: Starting bitbake server...
Task dependencies changed from:
['RUST_PANIC_STRATEGY', 'arch_to_rust_target_arch', 'prefix_for', 'rust_gen_target', 'sys_for']
to:

['BUILD_OS', 'BUILD_SYS', 'BUILD_VENDOR', 'DATA_LAYOUT', 'DATA_LAYOUT[aarch64]', 'DATA_LAYOUT[arm]', 'DATA_LAYOUT[armv7-eabi]', 'DATA_LAYOUT[i586]', 'DATA_LAYOUT[i686]', 'DATA_LAYOUT[mips64]', 'DATA_LAYOUT[mips64el]', 'DATA_LAYOUT[mips]', 'DATA_LAYOUT[mipsel]', 'DATA_LAYOUT[powerpc64]', 'DATA_LAYOUT[powerpc64le]', 'DATA_LAYOUT[powerpc]', 'DATA_LAYOUT[riscv32]', 'DATA_LAYOUT[riscv64]', 'DATA_LAYOUT[x86_64-x32]', 'DATA_LAYOUT[x86_64]', 'FEATURES', 'FEATURES[arm]', 'FEATURES[armv7-eabi]', 'HOST_ARCH', 'HOST_OS', 'HOST_SYS', 'HOST_VENDOR', 'LLVM_TARGET', 'LLVM_TARGET[aarch64]', 'LLVM_TARGET[arm]', 'LLVM_TARGET[armv7-eabi]', 'LLVM_TARGET[i586]', 'LLVM_TARGET[i686]', 'LLVM_TARGET[mips64]', 'LLVM_TARGET[mips64el]', 'LLVM_TARGET[mips]', 'LLVM_TARGET[mipsel]', 'LLVM_TARGET[powerpc64]', 'LLVM_TARGET[powerpc64le]', 'LLVM_TARGET[powerpc]', 'LLVM_TARGET[riscv32]', 'LLVM_TARGET[riscv64]', 'LLVM_TARGET[x86_64-x32]', 'LLVM_TARGET[x86_64]', 'MAX_ATOMIC_WIDTH', 'MAX_ATOMIC_WIDTH[aarch64]', 'MAX_ATOMIC_WIDTH[arm]', 'MAX_ATOMIC_WIDTH[armv7-eabi]', 'MAX_ATOMIC_WIDTH[i586]', 'MAX_ATOMIC_WIDTH[i686]', 'MAX_ATOMIC_WIDTH[mips64]', 'MAX_ATOMIC_WIDTH[mips64el]', 'MAX_ATOMIC_WIDTH[mips]', 'MAX_ATOMIC_WIDTH[mipsel]', 'MAX_ATOMIC_WIDTH[powerpc64]', 'MAX_ATOMIC_WIDTH[powerpc64le]', 'MAX_ATOMIC_WIDTH[powerpc]', 'MAX_ATOMIC_WIDTH[riscv32]', 'MAX_ATOMIC_WIDTH[riscv64]', 'MAX_ATOMIC_WIDTH[x86_64-x32]', 'MAX_ATOMIC_WIDTH[x86_64]', 'RUST_LIBC', 'RUST_LIBC:class-native', 'RUST_PANIC_STRATEGY', 'RUST_TARGET_SYS', 'TARGET_C_INT_WIDTH', 'TARGET_C_INT_WIDTH[aarch64]', 'TARGET_C_INT_WIDTH[arm]', 'TARGET_C_INT_WIDTH[armv7-eabi]', 'TARGET_C_INT_WIDTH[i586]', 'TARGET_C_INT_WIDTH[i686]', 'TARGET_C_INT_WIDTH[mips64]', 'TARGET_C_INT_WIDTH[mips64el]', 'TARGET_C_INT_WIDTH[mips]', 'TARGET_C_INT_WIDTH[mipsel]', 'TARGET_C_INT_WIDTH[powerpc64]', 'TARGET_C_INT_WIDTH[powerpc64le]', 'TARGET_C_INT_WIDTH[powerpc]', 'TARGET_C_INT_WIDTH[riscv32]', 'TARGET_C_INT_WIDTH[riscv64]', 'TARGET_C_INT_WIDTH[x86_64-x32]', 'TARGET_C_INT_WIDTH[x86_64]', 'TARGET_ENDIAN', 'TARGET_ENDIAN[aarch64]', 'TARGET_ENDIAN[arm]', 'TARGET_ENDIAN[armv7-eabi]', 'TARGET_ENDIAN[i586]', 'TARGET_ENDIAN[i686]', 'TARGET_ENDIAN[mips64]', 'TARGET_ENDIAN[mips64el]', 'TARGET_ENDIAN[mips]', 'TARGET_ENDIAN[mipsel]', 'TARGET_ENDIAN[powerpc64]', 'TARGET_ENDIAN[powerpc64le]', 'TARGET_ENDIAN[powerpc]', 'TARGET_ENDIAN[riscv32]', 'TARGET_ENDIAN[riscv64]', 'TARGET_ENDIAN[x86_64-x32]', 'TARGET_ENDIAN[x86_64]', 'TARGET_POINTER_WIDTH', 'TARGET_POINTER_WIDTH[aarch64]', 'TARGET_POINTER_WIDTH[arm]', 'TARGET_POINTER_WIDTH[armv7-eabi]', 'TARGET_POINTER_WIDTH[i586]', 'TARGET_POINTER_WIDTH[i686]', 'TARGET_POINTER_WIDTH[mips64]', 'TARGET_POINTER_WIDTH[mips64el]', 'TARGET_POINTER_WIDTH[mips]', 'TARGET_POINTER_WIDTH[mipsel]', 'TARGET_POINTER_WIDTH[powerpc64]', 'TARGET_POINTER_WIDTH[powerpc64le]', 'TARGET_POINTER_WIDTH[powerpc]', 'TARGET_POINTER_WIDTH[riscv32]', 'TARGET_POINTER_WIDTH[riscv64]', 'TARGET_POINTER_WIDTH[x86_64-x32]', 'TARGET_POINTER_WIDTH[x86_64]', 'arch_to_rust_target_arch', 'determine_libc', 'prefix_for', 'rust_base_triple', 'rust_gen_target', 'sys_for', 'target_is_armv7']

basehash changed from 6a46ad5360b899c64cb2b3f9a9d41de2977d6b86e86d7fe2f25cb8d07bdeae15 to 860b8f11b10182dc5b2737f62cdb697477f714adb63eeb4d4b932d67cac8eec2Dependency on variable DATA_LAYOUT was added

Dependency on variable DATA_LAYOUT[aarch64] was added
Dependency on variable DATA_LAYOUT[arm] was added
Dependency on variable DATA_LAYOUT[armv7-eabi] was added
Dependency on variable DATA_LAYOUT[i586] was added
Dependency on variable DATA_LAYOUT[i686] was added
Dependency on variable DATA_LAYOUT[mips64] was added

Also, I checked the sigdata update by changing the individual variable values. The build system detected the change in variable value and the sigdata updated. See below diffsigs output.

[skokkond@yow-fedora-builder1 buildB]$ bitbake-diffsigs -t rust-native do_rust_gen_targets
NOTE: Starting bitbake server...
basehash changed from 860b8f11b10182dc5b2737f62cdb697477f714adb63eeb4d4b932d67cac8eec2 to d0d2cd19aff93ae4223bbe765d75ca12f8e8bc3e3e270c5d15dd208419db73ae
Variable MAX_ATOMIC_WIDTH[armv7-eabi] value changed from '64' to '32'

I hope this fixes the sstate-cache issue. If yes, I'll send the updated patch and that can be taken to 'master' branch.


      
 The Yocto build system is not changing the signature of the Task when only
these variable changes are present (w/o the changes in 'rust_gen_target' task
definition).
 In the current patch, there are no changes in the 'rust_gen_target' task
definition and so the signature is not updated hence the 'rust_gen_target' task
is not rebuilded.
 I am not sure this behavior is a bug in Yocto or it is the expected behavior.
 Also, in the build config the MACHINE set as "beaglebone-yocto", and I expected
a change of signature in 'tmp/stamps/beaglebone_yocto-poky-linux-gnueabi/*' but
the sigdata file changed in 'tmp/stamps/x86_64-linux/rust-native'. I am looking
into it, but any clue here will be helpful.
That sounds like a bug and I'd have expected one of the oe-selftests to find
that. It might be that we need a "native" comparision test similar to those in
test_sstate_allarch_samesigs

(run as "oe-selftest -r test_sstate_allarch_samesigs")

I've to work on this test.


Cheers,

Richard