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 <[email protected]>
> > > ---
> > > 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165298):
https://lists.openembedded.org/g/openembedded-core/message/165298
Mute This Topic: https://lists.openembedded.org/mt/90389343/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
