linux.git/scripts/gdb/linux/cpus.py, branch v6.12.80

scripts/gdb: fix aarch64 userspace detection in get_current_task

2025-02-17T09:05:42+00:00

commit 4ebc417ef9cb34010a71270421fe320ec5d88aa2 upstream.

At least recent gdb releases (seen with 14.2) return SP_EL0 as signed long
which lets the right-shift always return 0.

Link: https://lkml.kernel.org/r/dcd2fabc-9131-4b48-8419-6444e2d67454@siemens.com
Signed-off-by: Jan Kiszka 
Cc: Barry Song 
Cc: Kieran Bingham 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

scripts/gdb: fix detection of current CPU in KGDB

2024-05-08T15:41:28+00:00

Directly read the current CPU number from the kgdb_active variable.

Before, the active CPU was obtained through the current task, which
required searching the task list for the pid of GDB's selected thread. 
Obtaining the pid was buggy: GDB may use selected_thread().ptid[1] (LWPID)
instead of .ptid[2] (TID) to store the threads pid; see
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads-In-Python.html
As a result, the detection could return the wrong CPU number, leading to
incorrect results for $lx_per_cpu and $lx_current.

As a side effect, the patch significantly speeds up $lx_per_cpu and
$lx_current in KGDB by avoiding the task-list iteration.

Link: https://lkml.kernel.org/r/20240425153501.749966-5-mail@florommel.de
Signed-off-by: Florian Rommel 
Cc: Andrew Jones 
Cc: Deepak Gupta 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Cc: Kuan-Ying Lee 
Cc: Palmer Dabbelt 
Signed-off-by: Andrew Morton

scripts/gdb: fix parameter handling in $lx_per_cpu

2024-05-08T15:41:28+00:00

Before, the script tried to get the address by constructing a pointer to
the parameter (by name).  However, since GDB now passes the parameter as a
GdbValue, we cannot get its name.  Instead, we retrieve the address
through GdbValue's address attribute.

Before:
>>> p $lx_per_cpu(cpu_info)
Traceback (most recent call last):
  File "./scripts/gdb/linux/cpus.py", line 152, in invoke
    var_ptr = gdb.parse_and_eval("&" + var_name.string())
                                       ^^^^^^^^^^^^^^^^^
gdb.error: Trying to read string with inappropriate type `struct cpuinfo_x86'.

Link: https://lkml.kernel.org/r/20240425153501.749966-3-mail@florommel.de
Signed-off-by: Florian Rommel 
Cc: Andrew Jones 
Cc: Deepak Gupta 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Cc: Kuan-Ying Lee 
Cc: Palmer Dabbelt 
Signed-off-by: Andrew Morton

scripts/gdb: add lx_current support for riscv

2023-11-01T19:46:59+00:00

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_sscratch CSR.

This patch assumes "tp" is pointing to task_struct. If value in
csr_sscratch is numerically greater than "tp" then it assumes csr_sscratch
is correct address of current task_struct. This logic holds when
   - hart is in user space, "tp" will be less than csr_sscratch.
   - hart is in kernel space but not in trap handler, "tp" will be more
     than csr_sscratch (csr_sscratch being equal to 0).
   - hart is executing trap handler
       - "tp" is still pointing to user mode but csr_sscratch contains
          ptr to task_struct. Thus numerically higher.
       - "tp" is  pointing to task_struct but csr_sscratch now contains
          either 0 or numerically smaller value (transiently holds
          user mode tp)

Link: https://lkml.kernel.org/r/20231026233837.612405-1-debug@rivosinc.com
Signed-off-by: Deepak Gupta 
Reviewed-by: Andrew Jones 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Tested-by: Hsieh-Tseng Shen 
Cc: Albert Ou 
Cc: Glenn Washburn 
Cc: Jan Kiszka 
Cc: Jeff Xie 
Cc: Kieran Bingham 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Signed-off-by: Andrew Morton

scripts/gdb: support getting current task struct in UML

2023-04-08T20:45:37+00:00

A running x86 UML kernel reports with architecture "i386:x86-64" as it is
a sub-architecture.  However, a difference with bare-metal x86 kernels is
in how it manages tasks and the current task struct.  To identify that the
inferior is a UML kernel and not bare-metal, check for the existence of
the UML specific symbol "cpu_tasks" which contains the current task
struct.

Link: https://lkml.kernel.org/r/b839d611e2906ccef2725c34d8e353fab35fe75e.1677469905.git.development@efficientek.com
Signed-off-by: Glenn Washburn 
Reviewed-by: Jan Kiszka 
Cc: Anton Ivanov 
Cc: Johannes Berg 
Cc: Kieran Bingham 
Cc: Richard Weinberger 
Signed-off-by: Andrew Morton

scripts/gdb: correct indentation in get_current_task

2023-04-08T20:45:36+00:00

Patch series "scripts/gdb: Support getting current task struct in UML",
v3.

A running x86 UML kernel reports with architecture "i386:x86-64" as it is
a sub-architecture.  However, a difference with bare-metal x86 kernels is
in how it manages tasks and the current task struct.  To identify that the
inferior is a UML kernel and not bare-metal, check for the existence of
the UML specific symbol "cpu_tasks" which contains the current task
struct.


This patch (of 3):

There is an extra space in a couple blocks in get_current_task.  Though
python does not care, let's make the spacing consistent.  Also, format
better an if expression, removing unneeded parenthesis.

Link: https://lkml.kernel.org/r/cover.1677469905.git.development@efficientek.com
Link: https://lkml.kernel.org/r/2e117b82240de6893f27cb6507242ce455ed7b5b.1677469905.git.development@efficientek.com
Signed-off-by: Glenn Washburn 
Reviewed-by: Jan Kiszka 
Cc: Anton Ivanov 
Cc: Johannes Berg 
Cc: Kieran Bingham 
Cc: Richard Weinberger 
Signed-off-by: Andrew Morton

scripts/gdb: fix 'lx-current' for x86

2023-02-09T23:56:51+00:00

When printing the name of the current process, it will report an error:
(gdb) p $lx_current().comm Python Exception  No symbol
"current_task" in current context.: Error occurred in Python: No symbol
"current_task" in current context.

Because e57ef2ed97c1 ("x86: Put hot per CPU variables into a struct")
changed it.

Link: https://lkml.kernel.org/r/20230204090139.1789264-1-xiehuan09@gmail.com
Fixes: e57ef2ed97c1 ("x86: Put hot per CPU variables into a struct")
Signed-off-by: Jeff Xie 
Cc: Jan Kiszka 
Cc: 
Signed-off-by: Andrew Morton

scripts/gdb: add lx_current support for arm64

2021-05-07T07:26:33+00:00

arm64 uses SP_EL0 to save the current task_struct address.  While running
in EL0, SP_EL0 is clobbered by userspace.  So if the upper bit is not 1
(not TTBR1), the current address is invalid.  This patch checks the upper
bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return
the derefrence of current task.  Otherwise, lx_current() will tell users
they are running in userspace(EL0).

While arm64 is running in EL0, it is actually pointless to print current
task as the memory of kernel space is not accessible in EL0.

Link: https://lkml.kernel.org/r/20210314203444.15188-3-song.bao.hua@hisilicon.com
Signed-off-by: Barry Song 
Cc: Jan Kiszka 
Cc: Jonathan Corbet 
Cc: Kieran Bingham 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

scripts/gdb: document lx_current is only supported by x86

2021-05-07T07:26:33+00:00

Patch series "scripts/gdb: clarify the platforms supporting lx_current and add arm64 support", v2.

lx_current depends on per_cpu current_task variable which exists on x86
only.  so it actually works on x86 only.  the 1st patch documents this
clearly; the 2nd patch adds support for arm64.

This patch (of 2):

x86 is the only architecture which has per_cpu current_task:

  arch$ git grep current_task | grep -i per_cpu
  x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task);
  x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) ____cacheline_aligned =
  x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
  x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task;
  x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
  x86/kernel/smpboot.c:	per_cpu(current_task, cpu) = idle;

On other architectures, lx_current() will lead to a python exception:

  (gdb) p $lx_current().pid
  Python Exception  No symbol "current_task" in current context.:
  Error occurred in Python: No symbol "current_task" in current context.

To avoid more people struggling and wasting time in other architectures,
document it.

Link: https://lkml.kernel.org/r/20210314203444.15188-1-song.bao.hua@hisilicon.com
Link: https://lkml.kernel.org/r/20210314203444.15188-2-song.bao.hua@hisilicon.com
Signed-off-by: Barry Song 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Cc: Jonathan Corbet 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

scripts/gdb: silence pep8 checks

2019-05-15T02:52:52+00:00

These scripts have some pep8 style warnings.  Fix them up so that this
directory is all pep8 clean.

Link: http://lkml.kernel.org/r/20190329220844.38234-6-swboyd@chromium.org
Signed-off-by: Stephen Boyd 
Cc: Douglas Anderson 
Cc: Nikolay Borisov 
Cc: Kieran Bingham 
Cc: Jan Kiszka 
Cc: Jackie Liu 
Cc: Jason Wessel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds