Re: [OE-core] [PATCH] gcc: Add riscv64 as a compatible host to gcc-sanitizers

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2024-02-12 at 03:00 -0800, Hemraj, Deepthi via
lists.openembedded.org wrote:
> From: Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
> 
> The issue address-sanitizer check failure arises when attempting to run a testcase compiled with AddressSanitizer on RISC-V 64 systems using the SV48 and SV57 virtual address scheme.
> This error occurs due to the lack of support for SV48 and SV57 in ASAN, which was originally designed for SV39 in Riscv64 architecture.
> This patch disables SV48 and SV57 support in QEMU and modifying the kernel to use SV39 by default.
> 
> Upstream-Status: Backport [https://github.com/google/sanitizers/issues/1707]
> Signed-off-by: Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
> ---
>  meta/recipes-devtools/gcc/gcc-sanitizers.inc  |  3 ++-
>  meta/recipes-devtools/qemu/qemu.inc           |  1 +
>  ...isable-sv48-sv57-support-for-riscv64.patch | 25 +++++++++++++++++++
>  3 files changed, 28 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/disable-sv48-sv57-support-for-riscv64.patch
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> index 524ebd4ba4..8c98e9cf8a 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> @@ -73,13 +73,14 @@ RRECOMMENDS:${PN}:append:x86 = " liblsan"
>  RRECOMMENDS:${PN}:append:x86-64 = " liblsan libtsan"
>  RRECOMMENDS:${PN}:append:powerpc64 = " liblsan libtsan"
>  RRECOMMENDS:${PN}:append:aarch64 = " liblsan libtsan"
> +RRECOMMENDS:${PN}:append:riscv64 = " liblsan libtsan"
>  
>  do_package_write_ipk[depends] += "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>  do_package_write_deb[depends] += "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>  do_package_write_rpm[depends] += "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>  
>  # Only x86, powerpc, sparc, s390, arm, aarch64 and loongarch64 are supported
> -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|sparc|s390|arm|aarch64|loongarch64).*-linux'
> +COMPATIBLE_HOST = '(x86_64|i.86|powerpc|sparc|s390|arm|aarch64|loongarch64|riscv64).*-linux'
>  # musl is currently broken entirely
>  COMPATIBLE_HOST:libc-musl = 'null'
>  
> diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
> index 2a81870151..56c988e7fd 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -36,6 +36,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
>             file://fix_segv.patch \
>             file://qemu-guest-agent.init \
>             file://qemu-guest-agent.udev \
> +	   file://disable-sv48-sv57-support-for-riscv64.patch \
>             "
>  UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar"
>  
> diff --git a/meta/recipes-devtools/qemu/qemu/disable-sv48-sv57-support-for-riscv64.patch b/meta/recipes-devtools/qemu/qemu/disable-sv48-sv57-support-for-riscv64.patch
> new file mode 100644
> index 0000000000..7f3eab1463
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/disable-sv48-sv57-support-for-riscv64.patch
> @@ -0,0 +1,25 @@
> +From: Deepthi Hemraj
> +Date: thur, 18 jan 2024 17:52:45
> +Subject: disable-sv48-sv57-support-for-riscv64 
> +
> +Disabling  48 & 57 bit virtual memory address in a RISC-V program, while the system's upper address limit resembles that of a 39-bit address space. 
> +This signals a lack of support for the 48 & 57 bit virtual address space on RISC-V; only the SV39 scheme is supported.
> +
> +Upstream-Status: Submitted [https://github.com/google/sanitizers/issues/1707]
> +Signed-off-by: Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
> +

This isn't true, it hasn't been submitted to qemu, it is listed as a
workaround in a different repository.

I think we need to get to the bottom of the issue before we can merge
something. If we do patch qemu (which I'm reluctant to do), the patch
does need to be accurate.

It is unclear what other side effects such a address space restriction
would have and would make us quite different from the architecture as
designed as I understand it.

Cheers,

Richard