Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Deepthi H <deepthi.hemraj@windriver.com>
To: Randy MacLeod <randy.macleod@windriver.com>,
	openembedded-core@lists.openembedded.org
Cc: Umesh.Kalappa@windriver.com, Naveen.Gowda@windriver.com,
	Shivaprasad.Moodalappa@windriver.com,
	Sundeep.Kokkonda@windriver.com, "Ramasamy,
	Rajeshkumar" <Rajeshkumar.Ramasamy@windriver.com>,
	"Hao, Kexin" <Kexin.Hao@windriver.com>
Subject: Re: [PATCH] gcc: Add riscv64 as a compatible host to gcc-sanitizers
Date: Tue, 13 Feb 2024 15:00:23 +0530	[thread overview]
Message-ID: <1ecab610-2732-4dd4-a1be-14eb6b3454c3@windriver.com> (raw)
In-Reply-To: <fcc39c54-1961-40ed-88fe-9303c8280bf1@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 5961 bytes --]


On 2/13/2024 1:31 AM, Randy MacLeod wrote:
> On 2024-02-12 2:49 p.m., Randy MacLeod wrote:
>> On 2024-02-12 6:00 a.m., Deepthi.Hemraj@windriver.com 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.
>>
>>
>> Deepthi,
>>
>> Thanks for looking into the gcc-sanitizers feature for qemuriscv64.
>>
>> I'm not sure if we want to make the qemu change that you have 
>> proposed and
>> since no one else has replied, I've looped in Kevin and Raj who may 
>> be able to
>> comment on the change.
>>
>> Oh, in reading over the comments to the issue linked below, I see:
>>   "As a temporary workaround for this problem"
>>
>> so I really doubt we want to make this change. Changing thevirtual 
>> address range for qemu is not to be undertaken lightly!
>>
>> Let's see what we hear from Kevin, Raj and upstream qemu over the 
>> coming week or two.
>>
>> To me, this is a '(very) nice to have' feature not a 'must have feature'
>> so if we have to wait until after Yocto-5.0, that's fine.
>>
> One more thing Deepthi,
>
> It would be good to add a test case similar to or extending:
>
>    meta/lib/oeqa/runtime/cases/gcc.py
>
> to ensure the feature does not regress.
>
Hi Randy,


Sure, We will work on this requirement with 15338 – address sanitizer 
self test (yoctoproject.org) 
<https://bugzilla.yoctoproject.org/show_bug.cgi?id=15338>


Thanks,

Deepthi.

> Thanks,
>
> ../Randy
>
>>> Upstream-Status: Backport [https://github.com/google/sanitizers/issues/1707]
>>
>> s/Backport/Submitted/
>>
>> as you have done below in the patch body.
>>
>>
>> Only commits merged to supported branches or master/main, should be 
>> labelled as back-ports
>>
>> Thanks,
>>
>> ../Randy
>>
>> `
>>
>>> 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>
>>> +
>>> +---
>>> +
>>> +diff --git a/target/riscv/csr.c b/target/riscv/csr.c
>>> +--- a/target/riscv/csr.c
>>> ++++ b/target/riscv/csr.c
>>> +@@ -1178,7 +1178,7 @@ const bool valid_vm_1_10_64[16] = {
>>> +     [VM_1_10_MBARE] = true,
>>> +     [VM_1_10_SV39] = true,
>>> +-    [VM_1_10_SV48] = true,
>>> +-    [VM_1_10_SV57] = true
>>> ++    [VM_1_10_SV48] = false,
>>> ++    [VM_1_10_SV57] = false
>>> + };
>>> +
>>> + /* Machine Information Registers */
>>
>>
>> -- 
>> # Randy MacLeod
>> # Wind River Linux
>
>
> -- 
> # Randy MacLeod
> # Wind River Linux

[-- Attachment #2: Type: text/html, Size: 8802 bytes --]

  reply	other threads:[~2024-02-13  9:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 11:00 [PATCH] gcc: Add riscv64 as a compatible host to gcc-sanitizers Deepthi.Hemraj
2024-02-12 19:49 ` Randy MacLeod
2024-02-12 20:01   ` Randy MacLeod
2024-02-13  9:30     ` Deepthi H [this message]
2024-02-13 22:06       ` Randy MacLeod
2024-02-13 13:55 ` [OE-core] " Richard Purdie
2024-02-13 22:04 ` Randy MacLeod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1ecab610-2732-4dd4-a1be-14eb6b3454c3@windriver.com \
    --to=deepthi.hemraj@windriver.com \
    --cc=Kexin.Hao@windriver.com \
    --cc=Naveen.Gowda@windriver.com \
    --cc=Rajeshkumar.Ramasamy@windriver.com \
    --cc=Shivaprasad.Moodalappa@windriver.com \
    --cc=Sundeep.Kokkonda@windriver.com \
    --cc=Umesh.Kalappa@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=randy.macleod@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox