| Message ID | 04960fa208fbd9c0962eb4f70aa45d28aec59e8d.1359463075.git.jan.kiszka@siemens.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Tue, Jan 29, 2013 at 01:37:59PM +0100, Jan Kiszka wrote: > This function allows to obtain a per-cpu variable, either of the current > or an explicitly specified CPU. > > Note: sparc64 version is untested. > > CC: "David S. Miller" <davem@davemloft.net> > CC: sparclinux@vger.kernel.org > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > scripts/gdb/percpu.py | 61 ++++++++++++++++++++++++++++++++++++++++++++ > scripts/gdb/vmlinux-gdb.py | 1 + > 2 files changed, 62 insertions(+), 0 deletions(-) > create mode 100644 scripts/gdb/percpu.py > > diff --git a/scripts/gdb/percpu.py b/scripts/gdb/percpu.py > new file mode 100644 > index 0000000..864962c > --- /dev/null > +++ b/scripts/gdb/percpu.py > @@ -0,0 +1,61 @@ > +# > +# gdb helper commands and functions for Linux kernel debugging > +# > +# per-cpu tools This is actually a very cool thing for CPU guys: it can show what kind of hybrid CPUs they've been glueing together, like the following, for example: ... (gdb) p $lx_per_cpu("cpu_info").x86_virt_bits $5 = 48 '0' (gdb) p $lx_per_cpu("cpu_info").x86_vendor_id $6 = "GenuineIntel\000\000\000" (gdb) p $lx_per_cpu("cpu_info").x86_model_id $7 = "AMD Phenom(tm) 9550 Quad-Core Processor", '\000' <repeats 24 times> (gdb) Since when does Intel produce CPUs called "AMD Phenom(tm) 9550 Quad-Core Processor"? .. hahaha.. > +# > +# Copyright (c) Siemens AG, 2011-2013 > +# > +# Authors: > +# Jan Kiszka <jan.kiszka@siemens.com> > +# > +# This work is licensed under the terms of the GNU GPL version 2. > +# > + > +import gdb > + > +from utils import * > +from task import * > + > +MAX_CPUS = 4096 > + > +def get_current_cpu(): > + if get_gdbserver_type() == GDBSERVER_QEMU: > + return gdb.selected_thread().num - 1 > + elif get_gdbserver_type() == GDBSERVER_KGDB: > + tid = gdb.selected_thread().ptid[2] > + if tid > (0x100000000 - MAX_CPUS - 2): > + return 0x100000000 - tid - 2 > + else: > + return get_thread_info(get_task_by_pid(tid))['cpu'] > + else: > + raise gdb.GdbError("Sorry, obtaining the current CPU is " > + "not yet supported with this gdb server.") > + > +def per_cpu(var_ptr, cpu): > + if cpu == -1: > + cpu = get_current_cpu() > + if is_target_arch("sparc:v9"): > + offset = gdb.parse_and_eval("trap_block[" + str(cpu) + > + "].__per_cpu_base") > + else: > + offset = gdb.parse_and_eval("__per_cpu_offset[" + str(cpu) + > + "]") > + pointer = var_ptr.cast(get_long_type()) + offset > + return pointer.cast(var_ptr.type).dereference() > + > + > +class PerCpu(gdb.Function): > + __doc__ = "Return per-cpu variable.\n" \ > + "\n" \ > + "$lx_per_cpu(\"VAR\"[, CPU]): Return the per-cpu variable called VAR for the\n" \ > + "given CPU number. If CPU is omitted, the CPU of the current context is used.\n" \ > + "Note that VAR has to be quoted as string." Ok, seriously now: apropos shows the "Return per-cpu... " line above. Have you found out which gdb command shows the rest? help and info both say "Undefined command". Thanks.
On 2013-01-29 14:51, Borislav Petkov wrote: > On Tue, Jan 29, 2013 at 01:37:59PM +0100, Jan Kiszka wrote: >> This function allows to obtain a per-cpu variable, either of the current >> or an explicitly specified CPU. >> >> Note: sparc64 version is untested. >> >> CC: "David S. Miller" <davem@davemloft.net> >> CC: sparclinux@vger.kernel.org >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> scripts/gdb/percpu.py | 61 ++++++++++++++++++++++++++++++++++++++++++++ >> scripts/gdb/vmlinux-gdb.py | 1 + >> 2 files changed, 62 insertions(+), 0 deletions(-) >> create mode 100644 scripts/gdb/percpu.py >> >> diff --git a/scripts/gdb/percpu.py b/scripts/gdb/percpu.py >> new file mode 100644 >> index 0000000..864962c >> --- /dev/null >> +++ b/scripts/gdb/percpu.py >> @@ -0,0 +1,61 @@ >> +# >> +# gdb helper commands and functions for Linux kernel debugging >> +# >> +# per-cpu tools > > This is actually a very cool thing for CPU guys: it can show what kind > of hybrid CPUs they've been glueing together, like the following, for > example: > > ... > (gdb) p $lx_per_cpu("cpu_info").x86_virt_bits > $5 = 48 '0' > (gdb) p $lx_per_cpu("cpu_info").x86_vendor_id > $6 = "GenuineIntel\000\000\000" > (gdb) p $lx_per_cpu("cpu_info").x86_model_id > $7 = "AMD Phenom(tm) 9550 Quad-Core Processor", '\000' <repeats 24 times> > (gdb) > > Since when does Intel produce CPUs called "AMD Phenom(tm) 9550 Quad-Core > Processor"? .. hahaha.. Let me guess: You are dumping a weird QEMU/KVM CPU, right? > >> +# >> +# Copyright (c) Siemens AG, 2011-2013 >> +# >> +# Authors: >> +# Jan Kiszka <jan.kiszka@siemens.com> >> +# >> +# This work is licensed under the terms of the GNU GPL version 2. >> +# >> + >> +import gdb >> + >> +from utils import * >> +from task import * >> + >> +MAX_CPUS = 4096 >> + >> +def get_current_cpu(): >> + if get_gdbserver_type() == GDBSERVER_QEMU: >> + return gdb.selected_thread().num - 1 >> + elif get_gdbserver_type() == GDBSERVER_KGDB: >> + tid = gdb.selected_thread().ptid[2] >> + if tid > (0x100000000 - MAX_CPUS - 2): >> + return 0x100000000 - tid - 2 >> + else: >> + return get_thread_info(get_task_by_pid(tid))['cpu'] >> + else: >> + raise gdb.GdbError("Sorry, obtaining the current CPU is " >> + "not yet supported with this gdb server.") >> + >> +def per_cpu(var_ptr, cpu): >> + if cpu == -1: >> + cpu = get_current_cpu() >> + if is_target_arch("sparc:v9"): >> + offset = gdb.parse_and_eval("trap_block[" + str(cpu) + >> + "].__per_cpu_base") >> + else: >> + offset = gdb.parse_and_eval("__per_cpu_offset[" + str(cpu) + >> + "]") >> + pointer = var_ptr.cast(get_long_type()) + offset >> + return pointer.cast(var_ptr.type).dereference() >> + >> + >> +class PerCpu(gdb.Function): >> + __doc__ = "Return per-cpu variable.\n" \ >> + "\n" \ >> + "$lx_per_cpu(\"VAR\"[, CPU]): Return the per-cpu variable called VAR for the\n" \ >> + "given CPU number. If CPU is omitted, the CPU of the current context is used.\n" \ >> + "Note that VAR has to be quoted as string." > > > Ok, seriously now: > > apropos shows the "Return per-cpu... " line above. Have you found out > which gdb command shows the rest? help and info both say "Undefined > command". help function lx_... It took me a while to find this, too. Jan
On Tue, Jan 29, 2013 at 02:56:56PM +0100, Jan Kiszka wrote: > Let me guess: You are dumping a weird QEMU/KVM CPU, right? Nah, I actually have the silicon! :-) Joking, of course. I wish. I'm booting the guest with -cpu phenom (it has been like that since forever in my boot-kernel-in-kvm script) but the host is Intel. If I do this on an AMD host, all is ok: (gdb) p $lx_per_cpu("cpu_info").x86_vendor_id $1 = "AuthenticAMD\000\000\000" (gdb) p $lx_per_cpu("cpu_info").x86_model_id $2 = "AMD Phenom(tm) 9550 Quad-Core Processor", '\000' <repeats 24 times> (gdb) [ … ] > >> +class PerCpu(gdb.Function): > >> + __doc__ = "Return per-cpu variable.\n" \ > >> + "\n" \ > >> + "$lx_per_cpu(\"VAR\"[, CPU]): Return the per-cpu variable called VAR for the\n" \ > >> + "given CPU number. If CPU is omitted, the CPU of the current context is used.\n" \ > >> + "Note that VAR has to be quoted as string." > > > > > > Ok, seriously now: > > > > apropos shows the "Return per-cpu... " line above. Have you found out > > which gdb command shows the rest? help and info both say "Undefined > > command". > > help function lx_... > > It took me a while to find this, too. Maybe worth documenting it then at the end of gdb-kernel-debugging.txt?
On 2013-01-29 15:12, Borislav Petkov wrote: > On Tue, Jan 29, 2013 at 02:56:56PM +0100, Jan Kiszka wrote: >> Let me guess: You are dumping a weird QEMU/KVM CPU, right? > > Nah, I actually have the silicon! :-) > > Joking, of course. I wish. I'm booting the guest with -cpu phenom (it > has been like that since forever in my boot-kernel-in-kvm script) but > the host is Intel. > > If I do this on an AMD host, all is ok: > > (gdb) p $lx_per_cpu("cpu_info").x86_vendor_id > $1 = "AuthenticAMD\000\000\000" > (gdb) p $lx_per_cpu("cpu_info").x86_model_id > $2 = "AMD Phenom(tm) 9550 Quad-Core Processor", '\000' <repeats 24 times> > (gdb) Remains a bug of QEMU, though possibly a minor one. > > [ … ] > >>>> +class PerCpu(gdb.Function): >>>> + __doc__ = "Return per-cpu variable.\n" \ >>>> + "\n" \ >>>> + "$lx_per_cpu(\"VAR\"[, CPU]): Return the per-cpu variable called VAR for the\n" \ >>>> + "given CPU number. If CPU is omitted, the CPU of the current context is used.\n" \ >>>> + "Note that VAR has to be quoted as string." >>> >>> >>> Ok, seriously now: >>> >>> apropos shows the "Return per-cpu... " line above. Have you found out >>> which gdb command shows the rest? help and info both say "Undefined >>> command". >> >> help function lx_... >> >> It took me a while to find this, too. > > Maybe worth documenting it then at the end of gdb-kernel-debugging.txt? > Done. Will come with v6 (if needed), otherwise as an add-on patch. Thanks, Jan
diff --git a/scripts/gdb/percpu.py b/scripts/gdb/percpu.py new file mode 100644 index 0000000..864962c --- /dev/null +++ b/scripts/gdb/percpu.py @@ -0,0 +1,61 @@ +# +# gdb helper commands and functions for Linux kernel debugging +# +# per-cpu tools +# +# Copyright (c) Siemens AG, 2011-2013 +# +# Authors: +# Jan Kiszka <jan.kiszka@siemens.com> +# +# This work is licensed under the terms of the GNU GPL version 2. +# + +import gdb + +from utils import * +from task import * + +MAX_CPUS = 4096 + +def get_current_cpu(): + if get_gdbserver_type() == GDBSERVER_QEMU: + return gdb.selected_thread().num - 1 + elif get_gdbserver_type() == GDBSERVER_KGDB: + tid = gdb.selected_thread().ptid[2] + if tid > (0x100000000 - MAX_CPUS - 2): + return 0x100000000 - tid - 2 + else: + return get_thread_info(get_task_by_pid(tid))['cpu'] + else: + raise gdb.GdbError("Sorry, obtaining the current CPU is " + "not yet supported with this gdb server.") + +def per_cpu(var_ptr, cpu): + if cpu == -1: + cpu = get_current_cpu() + if is_target_arch("sparc:v9"): + offset = gdb.parse_and_eval("trap_block[" + str(cpu) + + "].__per_cpu_base") + else: + offset = gdb.parse_and_eval("__per_cpu_offset[" + str(cpu) + + "]") + pointer = var_ptr.cast(get_long_type()) + offset + return pointer.cast(var_ptr.type).dereference() + + +class PerCpu(gdb.Function): + __doc__ = "Return per-cpu variable.\n" \ + "\n" \ + "$lx_per_cpu(\"VAR\"[, CPU]): Return the per-cpu variable called VAR for the\n" \ + "given CPU number. If CPU is omitted, the CPU of the current context is used.\n" \ + "Note that VAR has to be quoted as string." + + def __init__(self): + super(PerCpu, self).__init__("lx_per_cpu") + + def invoke(self, var_name, cpu = -1): + var_ptr = gdb.parse_and_eval("&" + var_name.string()) + return per_cpu(var_ptr, cpu) + +PerCpu() diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py index e1c5dbc..b143808 100644 --- a/scripts/gdb/vmlinux-gdb.py +++ b/scripts/gdb/vmlinux-gdb.py @@ -26,3 +26,4 @@ else: import module import dmesg import task + import percpu
This function allows to obtain a per-cpu variable, either of the current or an explicitly specified CPU. Note: sparc64 version is untested. CC: "David S. Miller" <davem@davemloft.net> CC: sparclinux@vger.kernel.org Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- scripts/gdb/percpu.py | 61 ++++++++++++++++++++++++++++++++++++++++++++ scripts/gdb/vmlinux-gdb.py | 1 + 2 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 scripts/gdb/percpu.py