On Mon, Dec 2, 2024 at 3:14 PM Randy MacLeod via
lists.openembedded.org
<randy.macleod=windriver....@lists.openembedded.org> wrote:
>
> On 2024-12-01 11:35 p.m., deepthi.hem...@windriver.com wrote:
>
> From: Deepthi Hemraj <deepthi.hem...@windriver.com>
>
> RISC-V offers several virtual memory address schemes (Sv39, Sv48, and Sv57),
> but ASan currently supports only Sv39 on RISC-V64.
> For RISC-V64 Sv39, ASan uses custom allocator configurations
> tuned to manage large allocations efficiently.
> These tunings are incompatible with larger address spaces like
> Sv48/Sv57 due to differences in region sizes and alignment.
>
> For riscv64, Asan's tuning for Sv39 can be enabled in qemu
> by using the appropriate flag in the command line as shown below:
> runqemu nographic qemuparams="-cpu rv64,sv39=true"
>
> Additionally, the COMPATIBLE_HOST list in gcc-sanitizers has been
> updated to include riscv64. All necessary tests were successfully
> conducted on both hardware(Microchip PolarFire SoC)
> and the qemurisv64 environment, with ASan effectively
> detecting memory errors in both scenarios.
>
>
> Hi Deepthi,
>
>
> Nice! Thanks for confirming that the qemu command line option allows
> gcc-sanitizers to
>
> work without any code changes.
>
>
> One concern is testing: testers would have know that this flag was needed for
> gcc-sanitizers.
>
> You could add a comment or documentation note as a hint but that doesn't
> automate and is error prone for people.
>
> I did note that "spacemonkeydelivers" (!) maintains that :
>
> "Indeed ASAN was ported to RISC-V when Sv39 was the default addressing mode,
> and changes to run it in Sv48/Sv57 must be made.
> The issue is related to the way how the address space is split between stack,
> heap and shadow versions of them."
> https://github.com/google/sanitizers/issues/1707#issuecomment-1852404560
its ok to use Sv39, other modes are not as common yet.
>
> so I don't think we've gotten to the best possible general purpose fix but
> rather a (helpful) work-around.
>
> I don't think we should merge this since there's more work to do for a proper
> fix.
>
> ../Randy
>
>
>
>
> Signed-off-by: Deepthi Hemraj <deepthi.hem...@windriver.com>
> ---
> meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> 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'
>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#208166):
https://lists.openembedded.org/g/openembedded-core/message/208166
Mute This Topic: https://lists.openembedded.org/mt/109874858/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
