diff mbox series

rust-target-config: fix cargo build with toolchain clang for riscv64

Message ID 20241120101429.209176-1-Harish.Sadineni@windriver.com
State New
Headers show
Series rust-target-config: fix cargo build with toolchain clang for riscv64 | expand

Commit Message

Sadineni, Harish Nov. 20, 2024, 10:14 a.m. UTC
From: Harish Sadineni <Harish.Sadineni@windriver.com>

bitbake cargo is getting failed when building  with toolchain clang
for riscv64 with the bellow error:

error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
   --> /usr/src/debug/cargo/1.79.0/rustc-1.79.0-src/vendor/dbus-0.9.7/src/ffidisp/connection.rs:298:50
    |
298 |         if r == -1 { Err(e) } else { Ok(unsafe { mem::transmute(r) }) }
    |                                                  ^^^^^^^^^^^^^^
    |
    = note: source type: `i32` (32 bits)
    = note: target type: `DBusRequestNameReply` (64 bits)

Issue will be fixed by changing TARGET_C_INT_WIDTH to 32 instead of 64.

Referred TARGET_C_INT_WIDTH for riscv64 from the following link:
https://docs.rs/crate/rustc-ap-rustc_target/587.0.0/source/spec/riscv64gc_unknown_none_elf.rs

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
---
 meta/classes-recipe/rust-target-config.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Randy MacLeod Nov. 20, 2024, 9:38 p.m. UTC | #1
Hi Harish,

I have some questions and comments below so please don't merge.

On 2024-11-20 5:14 a.m., Harish.Sadineni@windriver.com wrote:
> From: Harish Sadineni<Harish.Sadineni@windriver.com>
>
> bitbake cargo is getting failed when building  with toolchain clang
> for riscv64 with the bellow error:
>
> error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
>     --> /usr/src/debug/cargo/1.79.0/rustc-1.79.0-src/vendor/dbus-0.9.7/src/ffidisp/connection.rs:298:50
>      |
> 298 |         if r == -1 { Err(e) } else { Ok(unsafe { mem::transmute(r) }) }
>      |                                                  ^^^^^^^^^^^^^^
>      |
>      = note: source type: `i32` (32 bits)
>      = note: target type: `DBusRequestNameReply` (64 bits)
>
> Issue will be fixed by changing TARGET_C_INT_WIDTH to 32 instead of 64.
>
> Referred TARGET_C_INT_WIDTH for riscv64 from the following link:
> https://docs.rs/crate/rustc-ap-rustc_target/587.0.0/source/spec/riscv64gc_unknown_none_elf.rs

Can you explain that this link is and why we should trust it ?
What is the 587.0 part of the URL ? If I were paranoid, I'd think this 
was old data...
Indeed, this related link:
https://docs.rs/crate/rustc-ap-rustc_target/587.0.0/builds
seems to be from 2019.

If I look for a current version by changing the URL to:
https://docs.rs/crate/rustc-ap-rustc_target/latest
I just see:

|   rustc_target| contains some very low-level details that are specific 
to different compilation targets and so forth.

     For more information about how rustc works, see the rustc dev guide 
<https://rustc-dev-guide.rust-lang.org/>.

I'd like a v2 to fix the commit log.


>
> Signed-off-by: Harish Sadineni<Harish.Sadineni@windriver.com>
> ---
>   meta/classes-recipe/rust-target-config.bbclass | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass
> index f7aa6c74d8..d5fcfa1e2a 100644
> --- a/meta/classes-recipe/rust-target-config.bbclass
> +++ b/meta/classes-recipe/rust-target-config.bbclass
> @@ -247,7 +247,7 @@ MAX_ATOMIC_WIDTH[riscv32gc] = "32"
>   DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
>   TARGET_ENDIAN[riscv64gc] = "little"
>   TARGET_POINTER_WIDTH[riscv64gc] = "64"
> -TARGET_C_INT_WIDTH[riscv64gc] = "64"
> +TARGET_C_INT_WIDTH[riscv64gc] = "32"
>   MAX_ATOMIC_WIDTH[riscv64gc] = "64"
>   
>   ## loongarch64-unknown-linux-{gnu, musl}

I guess it avoids the error but how do we know if it's correct?
I'd like to see an RISCV64 doc that defines what these types should be.
I found this discussion:
https://github.com/riscv/riscv-isa-manual/issues/353
but didn't take time to find the published version of the doc; please do 
that.

For context, the value of this variable for all arches is below (1)

I did come across this Rust Github issue comment that warns us that
we've taken a risk that has exactly this type of consequence:

    I have recently discovered that yocto removes the very code that exists
    to check our data layouts against LLVM's, so that there is no drift 
or inaccuracy in
    ABI or code generation. This was done in yoctoproject/poky@c08c522 
<https://github.com/yoctoproject/poky/commit/c08c522fc29445aef0c64f0dd8df8a3531c04afa>

    "What this code was doing" was preventing things like this issue 
from occurring.
    That patch allows rustc's code generation to become unreliable.
    It allows usage of yocto's patched rustc by unwitting programmers 
against targets
    which we do not know the data layout for, thus cannot generate 
correct code for.
     ...

https://github.com/rust-lang/rust/issues/100687#issuecomment-2266368502

If one does't already exist, please open a defect in the YP bugzilla to 
track getting this fixed properly or
as Richard said in his commit log:
    "...resolve it by someone who has a better understanding of rust and 
what this code is doing. "
and report the link here.

By the way,  TARGET_C_INT_WIDTH goes all the way back to meta-clang:

commit 141177fbf9bb4c2b2d3625554d101d312e80f02a
Author: Johan Anderholm <johan.anderholm@gmail.com>
Date:   Sun Nov 26 08:43:20 2017

     rust: specify target-c-int-width

     The "target_c_int_width field is added to librustc_back since rust
     1.22.0 because not all rust targets (e.g. msp430-none-elf, avr)
     have 32-bit int types any more.


Finally,

Did you test runtime images built with gcc and clang? If you didn't 
check runtime can you at
least build and run helloworld.rs and for bonus points something that 
uses more rust, such as python3-cryptography?


../Randy



1)

❯ rg TARGET_C_INT_WIDTH meta/classes-recipe/rust-target-config.bbclass
136:TARGET_C_INT_WIDTH[arm-eabi] = "32"
144:TARGET_C_INT_WIDTH[armv7-eabi] = "32"
152:TARGET_C_INT_WIDTH[aarch64] = "32"
159:TARGET_C_INT_WIDTH[x86_64] = "32"
166:TARGET_C_INT_WIDTH[x86_64-x32] = "32"
173:TARGET_C_INT_WIDTH[i686] = "32"
180:TARGET_C_INT_WIDTH[i586] = "32"
187:TARGET_C_INT_WIDTH[mips] = "32"
194:TARGET_C_INT_WIDTH[mipsel] = "32"
201:TARGET_C_INT_WIDTH[mips64] = "64"
208:TARGET_C_INT_WIDTH[mips64-n32] = "32"
215:TARGET_C_INT_WIDTH[mips64el] = "64"
222:TARGET_C_INT_WIDTH[powerpc] = "32"
229:TARGET_C_INT_WIDTH[powerpc64] = "64"
236:TARGET_C_INT_WIDTH[powerpc64le] = "64"
243:TARGET_C_INT_WIDTH[riscv32gc] = "32"
250:TARGET_C_INT_WIDTH[riscv64gc] = "64"
257:TARGET_C_INT_WIDTH[loongarch64] = "32"
Richard Purdie Nov. 20, 2024, 9:46 p.m. UTC | #2
On Wed, 2024-11-20 at 16:38 -0500, Randy MacLeod via lists.openembedded.org wrote:
> ❯ rg TARGET_C_INT_WIDTH meta/classes-recipe/rust-target-
> config.bbclass
>  136:TARGET_C_INT_WIDTH[arm-eabi] = "32"
>  144:TARGET_C_INT_WIDTH[armv7-eabi] = "32"
>  152:TARGET_C_INT_WIDTH[aarch64] = "32"
>  159:TARGET_C_INT_WIDTH[x86_64] = "32"
>  166:TARGET_C_INT_WIDTH[x86_64-x32] = "32"
>  173:TARGET_C_INT_WIDTH[i686] = "32"
>  180:TARGET_C_INT_WIDTH[i586] = "32"
>  187:TARGET_C_INT_WIDTH[mips] = "32"
>  194:TARGET_C_INT_WIDTH[mipsel] = "32"
>  201:TARGET_C_INT_WIDTH[mips64] = "64"
>  208:TARGET_C_INT_WIDTH[mips64-n32] = "32"
>  215:TARGET_C_INT_WIDTH[mips64el] = "64"
>  222:TARGET_C_INT_WIDTH[powerpc] = "32"
>  229:TARGET_C_INT_WIDTH[powerpc64] = "64"
>  236:TARGET_C_INT_WIDTH[powerpc64le] = "64"
>  243:TARGET_C_INT_WIDTH[riscv32gc] = "32"
>  250:TARGET_C_INT_WIDTH[riscv64gc] = "64"
>  257:TARGET_C_INT_WIDTH[loongarch64] = "32"
>  

I was curious what our site files say:

meta/site$ grep sizeof_int -R
powerpc-darwin:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
nios2-linux:ac_cv_sizeof_char_p=${ac_cv_sizeof_int_p=4}
nios2-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
nios2-linux:ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
armeb-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mipsel-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
sparc-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
sh-common:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
microblaze-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mipsisa32r6-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mips-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
arm-linux:ac_cv_sizeof_char_p=${ac_cv_sizeof_int_p=4}
arm-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
arm-linux:ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
mips64el-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
powerpc32-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
powerpc32-linux:ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
powerpc32-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int='4'}
powerpc32-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mipsisa64r6-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
ix86-common:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
ix86-common:ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
mipsisa64r6el-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
x86_64-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mips64-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
mipsisa32r6el-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
powerpc64-linux:ac_cv_sizeof_int=${ac_cv_sizeof_int=4}

so it may be more than just riscv64 that is wrong there. mips and ppc
look incorrect too.

Cheers,

Richard
Khem Raj Nov. 21, 2024, 2:57 a.m. UTC | #3
On Wed, Nov 20, 2024 at 2:14 AM Sadineni, Harish via
lists.openembedded.org
<Harish.Sadineni=windriver.com@lists.openembedded.org> wrote:
>
> From: Harish Sadineni <Harish.Sadineni@windriver.com>
>
> bitbake cargo is getting failed when building  with toolchain clang
> for riscv64 with the bellow error:
>
> error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
>    --> /usr/src/debug/cargo/1.79.0/rustc-1.79.0-src/vendor/dbus-0.9.7/src/ffidisp/connection.rs:298:50
>     |
> 298 |         if r == -1 { Err(e) } else { Ok(unsafe { mem::transmute(r) }) }
>     |                                                  ^^^^^^^^^^^^^^
>     |
>     = note: source type: `i32` (32 bits)
>     = note: target type: `DBusRequestNameReply` (64 bits)
>
> Issue will be fixed by changing TARGET_C_INT_WIDTH to 32 instead of 64.
>

Thanks for looking into it.
Infact it should be 32 for all architectures not just rv64

> Referred TARGET_C_INT_WIDTH for riscv64 from the following link:
> https://docs.rs/crate/rustc-ap-rustc_target/587.0.0/source/spec/riscv64gc_unknown_none_elf.rs
>
> Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
> ---
>  meta/classes-recipe/rust-target-config.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass
> index f7aa6c74d8..d5fcfa1e2a 100644
> --- a/meta/classes-recipe/rust-target-config.bbclass
> +++ b/meta/classes-recipe/rust-target-config.bbclass
> @@ -247,7 +247,7 @@ MAX_ATOMIC_WIDTH[riscv32gc] = "32"
>  DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
>  TARGET_ENDIAN[riscv64gc] = "little"
>  TARGET_POINTER_WIDTH[riscv64gc] = "64"
> -TARGET_C_INT_WIDTH[riscv64gc] = "64"
> +TARGET_C_INT_WIDTH[riscv64gc] = "32"
>  MAX_ATOMIC_WIDTH[riscv64gc] = "64"
>
>  ## loongarch64-unknown-linux-{gnu, musl}
> --
> 2.43.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#207420): https://lists.openembedded.org/g/openembedded-core/message/207420
> Mute This Topic: https://lists.openembedded.org/mt/109681834/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
diff mbox series

Patch

diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass
index f7aa6c74d8..d5fcfa1e2a 100644
--- a/meta/classes-recipe/rust-target-config.bbclass
+++ b/meta/classes-recipe/rust-target-config.bbclass
@@ -247,7 +247,7 @@  MAX_ATOMIC_WIDTH[riscv32gc] = "32"
 DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
 TARGET_ENDIAN[riscv64gc] = "little"
 TARGET_POINTER_WIDTH[riscv64gc] = "64"
-TARGET_C_INT_WIDTH[riscv64gc] = "64"
+TARGET_C_INT_WIDTH[riscv64gc] = "32"
 MAX_ATOMIC_WIDTH[riscv64gc] = "64"
 
 ## loongarch64-unknown-linux-{gnu, musl}