Message ID | 20221115084923.1822572-1-debug@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2599646wru; Tue, 15 Nov 2022 01:02:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf7gucj2FlvC/LfCiFmHuBrur1qv6ZluT7pM7/Dt9+jiycAc9SL9wGNzX84eKaQ149bzFX/n X-Received: by 2002:a17:902:7892:b0:188:9568:1778 with SMTP id q18-20020a170902789200b0018895681778mr3015467pll.156.1668502950555; Tue, 15 Nov 2022 01:02:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668502950; cv=none; d=google.com; s=arc-20160816; b=sDN3kTby7xHFe+afsDsrHCzXNhbHuy2HeYTx26bMyCC7Z4sXy2qhAEyi1ywFSbzApq +FoOjlxgA2P4bbKun1dp2tjBuWzHSjx0C7QYhcVzLHQrCQjLck0wGs4JGAzS6O4i9DIA 9kWCAzMBKk/YWWbwukhiaFBD+XQe3BZ5HudPb5gZXUWh4LwxYcT2+P67lDEKX4uJVqct MmToUnNP3TYNVBXSUgtmN0S/4agcQAbrIsFDo0liXPhOtrWdU1WAX+kHtCsfiDQKZOZt HVsw+rveTXUrZcxUgeL8shcfpDdP8VUDXifKGG7Fm6W1/mjPvLYxrbHzfNgU+7PLk2Xc j31A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=qDByETx1OVv/ToHgra70XmddV8aLSLYjbfOVuUtVUdA=; b=Pj8NgZJbNtmCInBtqxWjM0ysoEhn1YHb0bgtd6DXk7tm8e2kypg2+tdGTge1Vh32Hf TBWbrKHhTbLyfKO+rui4arQa5tGvQmKUHIzw3iM9pLt/+pDqvUsgyH36VZNaQzosVPA+ pyqK84RLeW3cHVW+YSVInKiTO+1T7fe/+l7rKt9apFZOl3n29IDIxt2JXmaMoyzS5Zcp 1X3TanH2NmpOgLPwl2CTMn2QoPUOE0pWYly0s+WhLov59/jnmr9ZzLG00SuFGQ1jqyvH iJ1jHo8HOok8KkOuFzcZB6vmw2XXec7f5MJNIZcdHMhl8Ome90Gjel2mc2D9KBtubeUR idbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=efIjWq1q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s32-20020a63ff60000000b004607161e35dsi11077610pgk.830.2022.11.15.01.02.09; Tue, 15 Nov 2022 01:02:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=efIjWq1q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236873AbiKOItj (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Tue, 15 Nov 2022 03:49:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232870AbiKOIth (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 15 Nov 2022 03:49:37 -0500 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D83EF5B6 for <linux-kernel@vger.kernel.org>; Tue, 15 Nov 2022 00:49:36 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id l2so12523078pld.13 for <linux-kernel@vger.kernel.org>; Tue, 15 Nov 2022 00:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qDByETx1OVv/ToHgra70XmddV8aLSLYjbfOVuUtVUdA=; b=efIjWq1qpJbOkdAufChryyAS7BGpLb40UjUYYHCrOH4VmIF8UEsFamcHZpm9b3MCkr DBZDZyhpN8hrX8GXGIB/XTfbR6aH/zjQmgZC4WThNXjwv4E0yex2T4OEXFSHUp4ipSbu VuTbNYcPj25M2JP4LXssjHphTCgprCHIN1ExEqqZe3qyobBmMuXP7RfaDni79DQXL1+x UmSAnk7Twr34PFKD8egLFLJXYM8t09IhWUlIkwdXV9UenflcdzkhVZfNFtq9jc7R6ZiY UwIluASviXxgVcKTlZlF9BC+h6EyRkcPRFuNzhWTM2XR3TqfUrinh/8c0asCRaqTH6VM g+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qDByETx1OVv/ToHgra70XmddV8aLSLYjbfOVuUtVUdA=; b=Hi+bqz9RFW5KJNq9o9Xdelqdj1TrllCzdUWUpTwIWSvQ8hgpiuVdHAdAiE5XcWywji a773OU+xvPsNPliJfjNg51KaUcPL4oNDFjefIcVbuDEXMrn1usC4ScYSNid8NHUOc1/8 Q6Jqzu56r0dUyYyDII2FPuo6lRalNtFHvnkjDzrs7vGZ3wdhvvrY+5f5pmAYOrYajVni fsz4Byfq7C4suNybA+pRzRBf59qT1Kg7iylqidaWcPzjDvmUtf+WsHH8eX6uICyZRJxZ OFd7NkBoM03/W8FttQs4pIf1CzUSE9B48a8wdAirDvVXT0Bnk0sbE/HoCr885lU3oDA+ u8Eg== X-Gm-Message-State: ANoB5pnHmLpKvWvqJrkIzo/4ILchzXZ0jud0b1G4c223lVnhWQyTFae6 +MTwoo4iXr4JEX4qrr2EY8q0Eg== X-Received: by 2002:a17:90a:aa12:b0:218:4859:287c with SMTP id k18-20020a17090aaa1200b002184859287cmr1134445pjq.204.1668502176038; Tue, 15 Nov 2022 00:49:36 -0800 (PST) Received: from debug.ba.rivosinc.com ([66.220.2.162]) by smtp.gmail.com with ESMTPSA id w37-20020a631625000000b00464858cf6b0sm7224125pgl.54.2022.11.15.00.49.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 00:49:35 -0800 (PST) From: Deepak Gupta <debug@rivosinc.com> To: debug@rivosinc.com Cc: aou@eecs.berkeley.edu, jan.kiszka@siemens.com, kbingham@kernel.org, linux-kernel@vger.kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com Subject: [PATCH v3] scripts/gdb: add lx_current support for riscv Date: Tue, 15 Nov 2022 00:49:23 -0800 Message-Id: <20221115084923.1822572-1-debug@rivosinc.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221115012917.1781185-1-debug@rivosinc.com> References: <20221115012917.1781185-1-debug@rivosinc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749523804126868167?= X-GMAIL-MSGID: =?utf-8?q?1749552149976796958?= |
Series |
[v3] scripts/gdb: add lx_current support for riscv
|
|
Commit Message
Deepak Gupta
Nov. 15, 2022, 8:49 a.m. UTC
csr_sscratch CSR holds current task_struct address when hart is in
user space. Trap handler on entry spills csr_sscratch into "tp" (x2)
register and zeroes out csr_sscratch CSR. Trap handler on exit reloads
"tp" with expected user mode value and place current task_struct address
again in csr_scratch CSR.
This patch assumes "tp" is pointing to task_struct. If value in
csr_scratch is numerically greater than "tp" then it assumes csr_scratch
is correct address of current task_struct. This logic holds when
- hart is in user space, "tp" will be less than csr_scratch.
- hart is in kernel space but not in trap handler, "tp" will be more
than csr_scratch (csr_scratch being equal to 0).
- hart is executing trap handler
- "tp" is still pointing to user mode but csr_scratch contains
ptr to task_struct. Thus numerically higher.
- "tp" is pointing to task_struct but csr_scratch now contains
either 0 or numerically smaller value (transiently holds
user mode tp)
Patch also adds new cached type "ulong" in scripts/gdb/linux/utils.py
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
scripts/gdb/linux/cpus.py | 15 +++++++++++++++
scripts/gdb/linux/utils.py | 5 +++++
2 files changed, 20 insertions(+)
Comments
Hey Deepak, On Tue, Nov 15, 2022 at 12:49:23AM -0800, Deepak Gupta wrote: > csr_sscratch CSR holds current task_struct address when hart is in > user space. Trap handler on entry spills csr_sscratch into "tp" (x2) > register and zeroes out csr_sscratch CSR. Trap handler on exit reloads > "tp" with expected user mode value and place current task_struct address > again in csr_scratch CSR. > > This patch assumes "tp" is pointing to task_struct. If value in > csr_scratch is numerically greater than "tp" then it assumes csr_scratch nit: s/scratch/sscratch/ ? > is correct address of current task_struct. This logic holds when > - hart is in user space, "tp" will be less than csr_scratch. > - hart is in kernel space but not in trap handler, "tp" will be more > than csr_scratch (csr_scratch being equal to 0). > - hart is executing trap handler > - "tp" is still pointing to user mode but csr_scratch contains > ptr to task_struct. Thus numerically higher. > - "tp" is pointing to task_struct but csr_scratch now contains > either 0 or numerically smaller value (transiently holds > user mode tp) > > Patch also adds new cached type "ulong" in scripts/gdb/linux/utils.py > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> I noticed when looking into patchwork complaining about checkpatch errors in v2, that b4 had actually downloaded v3 but I could not see this patch on the RISC-V list. I don't see a changelog anywhere here from v2 either, nor did you pick up Drew's Reviewed-by. What's the story there? One really minor thing below. Should be able to fix it up trivially up & submit a v4, CCing the linux-riscv list. > --- > scripts/gdb/linux/cpus.py | 15 +++++++++++++++ > scripts/gdb/linux/utils.py | 5 +++++ > 2 files changed, 20 insertions(+) > > diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py > index 15fc4626d236..ca5215a660c7 100644 > --- a/scripts/gdb/linux/cpus.py > +++ b/scripts/gdb/linux/cpus.py > @@ -173,6 +173,21 @@ def get_current_task(cpu): > else: > raise gdb.GdbError("Sorry, obtaining the current task is not allowed " > "while running in userspace(EL0)") > + elif utils.is_target_arch("riscv"): > + current_tp = gdb.parse_and_eval("$tp") > + scratch_reg = gdb.parse_and_eval("$sscratch") > + > + # by default tp points to current task > + current_task = current_tp.cast(task_ptr_type) > + > + # scratch register is set 0 in trap handler after entering kernel. > + # When hart is in user mode, scratch register is pointing to task_struct. > + # and tp is used by user mode. So when scratch register holds larger value > + # (negative address as ulong is larger value) than tp, then use scratch register. > + if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): ^^ extra space here? > + current_task = scratch_reg.cast(task_ptr_type) > + > + return current_task.dereference() > else: > raise gdb.GdbError("Sorry, obtaining the current task is not yet " > "supported with this arch") > diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py > index 1553f68716cc..ddaf3089170d 100644 > --- a/scripts/gdb/linux/utils.py > +++ b/scripts/gdb/linux/utils.py > @@ -35,12 +35,17 @@ class CachedType: > > > long_type = CachedType("long") > +ulong_type = CachedType("ulong") > atomic_long_type = CachedType("atomic_long_t") > > def get_long_type(): > global long_type > return long_type.get_type() > > +def get_ulong_type(): > + global ulong_type > + return ulong_type.get_type() > + > def offset_of(typeobj, field): > element = gdb.Value(0).cast(typeobj) > return int(str(element[field].address).split()[0], 16) > -- > 2.25.1
Hey Deepak, On 15/11/2022 17:49, Deepak Gupta wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > Since I am new to all this. I've had some oversight and am still learning the flow. > Rest inline. No worries chief. Worth noting is that this mail came in html form, which the mailing lists reject. Noone outside of the direct CC list will see this mail. May be worth asking some of the other Rivos lads how they do their plain text emailing. ik Palmer's got his hand rolled stuff, so maybe he's not the best to ask - but try Bjorn or Atish? > > On Tue, Nov 15, 2022 at 6:38 AM Conor Dooley <conor.dooley@microchip.com <mailto:conor.dooley@microchip.com>> wrote: > > Hey Deepak, > > On Tue, Nov 15, 2022 at 12:49:23AM -0800, Deepak Gupta wrote: > > csr_sscratch CSR holds current task_struct address when hart is in > > user space. Trap handler on entry spills csr_sscratch into "tp" (x2) > > register and zeroes out csr_sscratch CSR. Trap handler on exit reloads > > "tp" with expected user mode value and place current task_struct address > > again in csr_scratch CSR. > > > > This patch assumes "tp" is pointing to task_struct. If value in > > csr_scratch is numerically greater than "tp" then it assumes csr_scratch > > nit: s/scratch/sscratch/ ? > > > Will fix it. > > > > > is correct address of current task_struct. This logic holds when > > - hart is in user space, "tp" will be less than csr_scratch. > > - hart is in kernel space but not in trap handler, "tp" will be more > > than csr_scratch (csr_scratch being equal to 0). > > - hart is executing trap handler > > - "tp" is still pointing to user mode but csr_scratch contains > > ptr to task_struct. Thus numerically higher. > > - "tp" is pointing to task_struct but csr_scratch now contains > > either 0 or numerically smaller value (transiently holds > > user mode tp) > > > > Patch also adds new cached type "ulong" in scripts/gdb/linux/utils.py > > > > Signed-off-by: Deepak Gupta <debug@rivosinc.com <mailto:debug@rivosinc.com>> > > I noticed when looking into patchwork complaining about checkpatch > errors in v2, that b4 had actually downloaded v3 but I could not see > this patch on the RISC-V list. > > > I'll make sure to add the risc-v list on the next spin up. > > > I don't see a changelog anywhere here > from v2 either > > > I had been taking inputs and squashing commits on my end. > You want me to send a changelog of changes between versions of patches. Yeah, it's nice to say something like: v2 -> v3: - reworded commit message - fixed compile error in bar.c if !CONFIG_FOO Makes it easier for reviewers to see what changed between versions. > > > , nor did you pick up Drew's Reviewed-by. > > > I should've done that. My mistake and apologize. > I'll fix it in my next submission. > > > > What's the story there? > > One really minor thing below. Should be able to fix it up trivially up > & submit a v4, CCing the linux-riscv list. > > > --- > > scripts/gdb/linux/cpus.py | 15 +++++++++++++++ > > scripts/gdb/linux/utils.py | 5 +++++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py > > index 15fc4626d236..ca5215a660c7 100644 > > --- a/scripts/gdb/linux/cpus.py > > +++ b/scripts/gdb/linux/cpus.py > > @@ -173,6 +173,21 @@ def get_current_task(cpu): > > else: > > raise gdb.GdbError("Sorry, obtaining the current task is not allowed " > > "while running in userspace(EL0)") > > + elif utils.is_target_arch("riscv"): > > + current_tp = gdb.parse_and_eval("$tp") > > + scratch_reg = gdb.parse_and_eval("$sscratch") > > + > > + # by default tp points to current task > > + current_task = current_tp.cast(task_ptr_type) > > + > > + # scratch register is set 0 in trap handler after entering kernel. > > + # When hart is in user mode, scratch register is pointing to task_struct. > > + # and tp is used by user mode. So when scratch register holds larger value > > + # (negative address as ulong is larger value) than tp, then use scratch register. > > + if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): > ^^ > extra space here? > > > I don't see the space in the patch. Can you clarify which space you're talking about here? There's a double space between the > and current_tp. I put a ^^ under it, but if you've not got a monospace font, which since you're replying in html you probably don't, it may not align for you. Hope that helps, Conor. > > > > > > + current_task = scratch_reg.cast(task_ptr_type) > > + > > + return current_task.dereference() > > else: > > raise gdb.GdbError("Sorry, obtaining the current task is not yet " > > "supported with this arch") > > diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py > > index 1553f68716cc..ddaf3089170d 100644 > > --- a/scripts/gdb/linux/utils.py > > +++ b/scripts/gdb/linux/utils.py > > @@ -35,12 +35,17 @@ class CachedType: > > > > > > long_type = CachedType("long") > > +ulong_type = CachedType("ulong") > > atomic_long_type = CachedType("atomic_long_t") > > > > def get_long_type(): > > global long_type > > return long_type.get_type() > > > > +def get_ulong_type(): > > + global ulong_type > > + return ulong_type.get_type() > > + > > def offset_of(typeobj, field): > > element = gdb.Value(0).cast(typeobj) > > return int(str(element[field].address).split()[0], 16) > > -- > > 2.25.1 >
On Tue, Nov 15, 2022 at 09:49:10AM -0800, Deepak Gupta wrote: ... > On Tue, Nov 15, 2022 at 6:38 AM Conor Dooley <conor.dooley@microchip.com> > wrote: > > > Hey Deepak, > > > > On Tue, Nov 15, 2022 at 12:49:23AM -0800, Deepak Gupta wrote: ... > > > + if (scratch_reg.cast(utils.get_ulong_type()) > > > current_tp.cast(utils.get_ulong_type())): > > ^^ > > extra space here? > > > I don't see the space in the patch. Can you clarify which space you're > talking about here? The same one I pointed out in v2. The one after the greater-than sign. Is your editor not using a monospaced font? Thanks, drew
On Tue, Nov 15, 2022 at 06:06:34PM +0000, Conor.Dooley@microchip.com wrote: >Hey Deepak, > >On 15/11/2022 17:49, Deepak Gupta wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> Since I am new to all this. I've had some oversight and am still learning the flow. >> Rest inline. > >No worries chief. Worth noting is that this mail came in html >form, which the mailing lists reject. Noone outside of the >direct CC list will see this mail. May be worth asking some >of the other Rivos lads how they do their plain text emailing. > >ik Palmer's got his hand rolled stuff, so maybe he's not the >best to ask - but try Bjorn or Atish? Sending this time from mutt. Hopefully no bounces. > >> >> On Tue, Nov 15, 2022 at 6:38 AM Conor Dooley <conor.dooley@microchip.com <mailto:conor.dooley@microchip.com>> wrote: >> >> Hey Deepak, >> >> On Tue, Nov 15, 2022 at 12:49:23AM -0800, Deepak Gupta wrote: >> > csr_sscratch CSR holds current task_struct address when hart is in >> > user space. Trap handler on entry spills csr_sscratch into "tp" (x2) >> > register and zeroes out csr_sscratch CSR. Trap handler on exit reloads >> > "tp" with expected user mode value and place current task_struct address >> > again in csr_scratch CSR. >> > >> > This patch assumes "tp" is pointing to task_struct. If value in >> > csr_scratch is numerically greater than "tp" then it assumes csr_scratch >> >> nit: s/scratch/sscratch/ ? >> >> >> Will fix it. >> >> >> >> > is correct address of current task_struct. This logic holds when >> > - hart is in user space, "tp" will be less than csr_scratch. >> > - hart is in kernel space but not in trap handler, "tp" will be more >> > than csr_scratch (csr_scratch being equal to 0). >> > - hart is executing trap handler >> > - "tp" is still pointing to user mode but csr_scratch contains >> > ptr to task_struct. Thus numerically higher. >> > - "tp" is pointing to task_struct but csr_scratch now contains >> > either 0 or numerically smaller value (transiently holds >> > user mode tp) >> > >> > Patch also adds new cached type "ulong" in scripts/gdb/linux/utils.py >> > >> > Signed-off-by: Deepak Gupta <debug@rivosinc.com <mailto:debug@rivosinc.com>> >> >> I noticed when looking into patchwork complaining about checkpatch >> errors in v2, that b4 had actually downloaded v3 but I could not see >> this patch on the RISC-V list. >> >> >> I'll make sure to add the risc-v list on the next spin up. >> >> >> I don't see a changelog anywhere here >> from v2 either >> >> >> I had been taking inputs and squashing commits on my end. >> You want me to send a changelog of changes between versions of patches. > >Yeah, it's nice to say something like: >v2 -> v3: >- reworded commit message >- fixed compile error in bar.c if !CONFIG_FOO > >Makes it easier for reviewers to see what changed between >versions. > >> >> >> , nor did you pick up Drew's Reviewed-by. >> >> >> I should've done that. My mistake and apologize. >> I'll fix it in my next submission. >> >> >> >> What's the story there? >> >> One really minor thing below. Should be able to fix it up trivially up >> & submit a v4, CCing the linux-riscv list. >> >> > --- >> > scripts/gdb/linux/cpus.py | 15 +++++++++++++++ >> > scripts/gdb/linux/utils.py | 5 +++++ >> > 2 files changed, 20 insertions(+) >> > >> > diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py >> > index 15fc4626d236..ca5215a660c7 100644 >> > --- a/scripts/gdb/linux/cpus.py >> > +++ b/scripts/gdb/linux/cpus.py >> > @@ -173,6 +173,21 @@ def get_current_task(cpu): >> > else: >> > raise gdb.GdbError("Sorry, obtaining the current task is not allowed " >> > "while running in userspace(EL0)") >> > + elif utils.is_target_arch("riscv"): >> > + current_tp = gdb.parse_and_eval("$tp") >> > + scratch_reg = gdb.parse_and_eval("$sscratch") >> > + >> > + # by default tp points to current task >> > + current_task = current_tp.cast(task_ptr_type) >> > + >> > + # scratch register is set 0 in trap handler after entering kernel. >> > + # When hart is in user mode, scratch register is pointing to task_struct. >> > + # and tp is used by user mode. So when scratch register holds larger value >> > + # (negative address as ulong is larger value) than tp, then use scratch register. >> > + if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): >> ^^ >> extra space here? >> >> >> I don't see the space in the patch. Can you clarify which space you're talking about here? > >There's a double space between the > and current_tp. >I put a ^^ under it, but if you've not got a monospace font, which since >you're replying in html you probably don't, it may not align for you. > >Hope that helps, >Conor. Yes can see it now. > >> >> >> >> >> > + current_task = scratch_reg.cast(task_ptr_type) >> > + >> > + return current_task.dereference() >> > else: >> > raise gdb.GdbError("Sorry, obtaining the current task is not yet " >> > "supported with this arch") >> > diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py >> > index 1553f68716cc..ddaf3089170d 100644 >> > --- a/scripts/gdb/linux/utils.py >> > +++ b/scripts/gdb/linux/utils.py >> > @@ -35,12 +35,17 @@ class CachedType: >> > >> > >> > long_type = CachedType("long") >> > +ulong_type = CachedType("ulong") >> > atomic_long_type = CachedType("atomic_long_t") >> > >> > def get_long_type(): >> > global long_type >> > return long_type.get_type() >> > >> > +def get_ulong_type(): >> > + global ulong_type >> > + return ulong_type.get_type() >> > + >> > def offset_of(typeobj, field): >> > element = gdb.Value(0).cast(typeobj) >> > return int(str(element[field].address).split()[0], 16) >> > -- >> > 2.25.1 >> >
diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py index 15fc4626d236..ca5215a660c7 100644 --- a/scripts/gdb/linux/cpus.py +++ b/scripts/gdb/linux/cpus.py @@ -173,6 +173,21 @@ def get_current_task(cpu): else: raise gdb.GdbError("Sorry, obtaining the current task is not allowed " "while running in userspace(EL0)") + elif utils.is_target_arch("riscv"): + current_tp = gdb.parse_and_eval("$tp") + scratch_reg = gdb.parse_and_eval("$sscratch") + + # by default tp points to current task + current_task = current_tp.cast(task_ptr_type) + + # scratch register is set 0 in trap handler after entering kernel. + # When hart is in user mode, scratch register is pointing to task_struct. + # and tp is used by user mode. So when scratch register holds larger value + # (negative address as ulong is larger value) than tp, then use scratch register. + if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): + current_task = scratch_reg.cast(task_ptr_type) + + return current_task.dereference() else: raise gdb.GdbError("Sorry, obtaining the current task is not yet " "supported with this arch") diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py index 1553f68716cc..ddaf3089170d 100644 --- a/scripts/gdb/linux/utils.py +++ b/scripts/gdb/linux/utils.py @@ -35,12 +35,17 @@ class CachedType: long_type = CachedType("long") +ulong_type = CachedType("ulong") atomic_long_type = CachedType("atomic_long_t") def get_long_type(): global long_type return long_type.get_type() +def get_ulong_type(): + global ulong_type + return ulong_type.get_type() + def offset_of(typeobj, field): element = gdb.Value(0).cast(typeobj) return int(str(element[field].address).split()[0], 16)