Created attachment 4923 [details] Bash script to reproduce the error. Run with no arguments. While trying to build rust/libstd-rs for an arm architecture, the build failed. | error: could not compile `core`; 2 warnings emitted | | Caused by: | process didn't exit successfully: `rustc --crate-name core --edition=2018 library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=d730d99aec694355 -C extra-filename=-d730d99aec694355 --out-dir /home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/build/arm-poky-linux-gnueabi/release/deps --target arm-poky-linux-gnueabi -C linker=/home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/wrapper/target-rust-ccld -L dependency=/home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/build/arm-poky-linux-gnueabi/release/deps -L dependency=/home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/build/release/deps -L /home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/recipe-sysroot/usr/lib/rust --remap-path-prefix=/home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0=/usr/src/debug/libstd-rs/1.59.0-r0 -Cembed-bitcode=yes -L /home/mabnhdev/meson-repro-arm/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/libstd-rs/1.59.0-r0/recipe-sysroot/usr/lib -C link-arg=-Wl,-soname,libstd.so` (signal: 11, SIGSEGV: invalid memory reference) I've enclosed a bash script that will reproduce the problem. I've also enclosed the full build log.
Created attachment 4924 [details] Build log.
Yash, can you reproduce this error on kirkstone? How about on master?
The attached bash script will reproduce in Kirkstone.
I was able to reproduce the error in HEAD.
(In reply to comment #2) > Yash, can you reproduce this error on kirkstone? How about on master? This error is reproducible in both master and kirkstone.
Hi. This issue was originally targeted at 4.0.8 and then changed to 4.0.9. This is a blocking issue for my project at I do have to support an arm-based host and my "deadline" to complete the upgrade to Kirkstone is coming in a few months. If this will truly be fixed in 4.0.9, then that should work for me. However, if it is not fixed in 4.0.9, I will probably need to come up with some workaround so I can progress on my project. Is there a workaround available to would allow me to complete the build for my arm target?
(In reply to mabnhdev from comment #6) > Hi. This issue was originally targeted at 4.0.8 and then changed to 4.0.9. > This is a blocking issue for my project at I do have to support an arm-based > host and my "deadline" to complete the upgrade to Kirkstone is coming in a > few months. > > If this will truly be fixed in 4.0.9, then that should work for me. > However, if it is not fixed in 4.0.9, I will probably need to come up with > some workaround so I can progress on my project. > > Is there a workaround available to would allow me to complete the build for > my arm target? There is no workaround available as of now. As the build date for 4.0.9 has passed, is it fine to provide a fix by the next release, i.e. 4.0.10?
> There is no workaround available as of now. As the build date for 4.0.9 has > passed, is it fine to provide a fix by the next release, i.e. 4.0.10? Yes, please target the 4.0.10 release!
(In reply to Yash Shinde from comment #7) > There is no workaround available as of now. As the build date for 4.0.9 has > passed, is it fine to provide a fix by the next release, i.e. 4.0.10? I hadn't realized 4.0.9 was already done. If 4.0.10 is available in a month or two, that should work for me. At worse, I could advance my repo or cherry-pick your fix whenever you commit it. Thanks.
Hello mabnhdev, For cortexa9 the default fpu tuning is "softfp". By setting TARGET_FPU = "softfp" in script this build error is solved. We need to analyze yet the fpu tuning "soft" is not supported or why it is causing the build failure. Anyway, if this quick workaround/fix OK then you can use it.
Sundeep, thanks for the tip. Mike, Yocto project work is a volunteer activity for the members involved, some of whom work at companies like Wind River that provide Yocto-based products. Neither Yash nor anyone else should commit to a specific timeline for most Yocto bugs since in his case, other business needs will take priority. Yash will do what he can but if you have an urgent business need, then you should either: 1. resolve the problem yourself and send a patch, 2. hire a consultant or 3. contract with a company, such as WR, that provides an SLA for Yocto bug resolution. 4. Use Sundeep's work-around. That said, this problem appears to affect the master branch as well as kirkstone so Yash, please work on the problem on master and then we can backport a fix to 4.0.x if that isn't too much work or too intrusive. Thanks, Randy
(In reply to Sundeep Kokkonda from comment #10) > Hello mabnhdev, > > For cortexa9 the default fpu tuning is "softfp". By setting TARGET_FPU = > "softfp" in script this build error is solved. > We need to analyze yet the fpu tuning "soft" is not supported or why it is > causing the build failure. > > Anyway, if this quick workaround/fix OK then you can use it. Good suggestion - using "softfp" does avoid the build failure. However, I am targeting a Broadcom XGS iProc 32-bit ARM core which does not like "softfp" fpu tuning. I tried it just for giggles and my image crashed and burned as soon as the Linux kernel began initialization. So, for the time being, I am stuck with using "soft" for fpu tuning as in the repro script. Thanks again for the suggestion, though.
As per the given bash script, cortex-a9 is the target arch. The build is success with 'softfp' which is the default tuning for this arch. And, according to the ARM docs referred, it is known that ARM cortex-a9 supports "SOFT" which is basically generates software floating point instructions alone. Also, there are several variants & tunings for cortexa9 (tune-cortexa9, tune-cortexa9t, tune-cortexa9-neon, vfp extensions.. etc) are there in the poky conf files. So, it is to be understood that these tuning options are used correctly or not. Also, these tuning options are causing the problem or the generated rustc_driver or any other dependent libs in poky are buggy to be analyzed (Since we've seen such a similar seg fault with 32-bit machines but with Debug enabled). @mabnhdev: Does this tuning worked anytime earlier? What is the exact fpu options used? The https://www.haoyuelectronics.com/service/RK3066/reference/Cortex_a9_fpu_r4p0_trm-Technical%20Reference%20Manual%20ARM%20Cortex-A9%20FPU.pdf (pg.10) says that the FPU is a VFPv3-D16. (https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Option-to-specify-the-FPU#:~:text=Cortex-A9,mfpu%3Dneon-fp16) Let us know if you have any updates.
@mabnhdev: Gentle remainder. Can you let us know 'Does this tuning worked anytime earlier? What is the exact fpu options used?' Also, can you let us know the exact micro variant of armv9 to check the right tuning parameters.
Apologies for the late reply. This configuration (o32 bigendian fpu-hard octeon2) worked as late as Dunfell. I am trying to upgrade from Dunfell to Kirkstone, so I have not tried anything between Dunfell and Kirkstone. I've worked around the problem by changing my tuning to 'softfp' as recommended earlier. All is building fine for me now. I'm not sure what you mean by "micro-variant".
Sundeep, Yash, Please ask a follow-up question or move the bug out of the Need-Info state.
(In reply to mabnhdev from comment #15) > Apologies for the late reply. > > This configuration (o32 bigendian fpu-hard octeon2) worked as late as > Dunfell. I am trying to upgrade from Dunfell to Kirkstone, so I have not > tried anything between Dunfell and Kirkstone. > > I've worked around the problem by changing my tuning to 'softfp' as > recommended earlier. All is building fine for me now. > > I'm not sure what you mean by "micro-variant". arm7/armv7/armv7a/arm<<***>> are different micro-variants based on which several FPU/VFP tune configs are in yocto file "meta/conf/machine/include/arm/armv7a/tune-cortexa9.inc". Let us know the exact micro variant to check the right tuning parameters.
The CPU in question is a single core Cortex-A9, so the micro-variant is ARMv7-A.
Revising an earlier comment, the configuration is (arm vfp cortexa9) and it worked fine as late as Dunfell. Please disregard the configuration I gave in Comment #15 - that is for a different platform.
With the rust 1.70 update in Yocto (master), the below change in 'rust-common.inc' is fixing this issue. meta/recipes-devtools/rust/rust-common.inc if 'neon' in feat: f.append("+neon") + elif target_is_armv7(d): + f.append("-neon") if 'mips32' in feat: f.append("+mips32") Please check and let us know if the issue is solved.
@mabnhdev: Can you check the solution provided in Comment 20 and let us know your feedback.
Ross, We didn't get a reply from the reporter. What do you think of this arm specific fix?
Looks like this got fixed as part of d79f0a0702b667625e12c9e131932e02cb08bada, which added that line (among others).