Failing to evaluate - You can't do that without a process to debug #30
Comments
|
----- Original Message -----
As I am able to evaluate two values (casting pointers to `uint`s) - I should
be able to figure out the distance between said pointers (note - don't want
pointer math)
As can be seen I can evaluate each cated-pointer as can be seen in `$39` & `$40`
but when i try to evaluate/print the byte-delta between those `crash` reports
an error from ``gdb`, but if i force it into `gdb` as can be seen in the
last line it just works. So looks like something in the `crash`
command-line processing is eating up the `-` (minus)
```
crash> p ((uint)((struct sk_buff*)0xe47d9900)->tail)
$39 = 3778076956
crash> p ((uint)((struct sk_buff*)0xe47d9900)->data)
$40 = 3778076872
crash> p (((uint)((struct sk_buff*)0xe47d9900)->tail) - ((uint)((struct sk_buff*)0xe47d9900)->data))
You can't do that without a process to debug.
p: gdb request failed: p (((uint)((struct sk_buff*)0xe47d9900)->tail) ((uint)((struct sk_buff*)0xe47d9900)->data))
crash> gdb p (((uint)((struct sk_buff*)0xe47d9900)->tail) - ((uint)((struct sk_buff*)0xe47d9900)->data))
$41 = 84
```
Yeah, the call from cmp_p() to concat_args() is purposefully extracting it.
/*
* Concatenates the tokens in the global args[] array into one string,
* separating each token with one space. If the no_options flag is set,
* don't include any args beginning with a dash character.
*/
char *
concat_args(char *buf, int arg, int no_options)
{
int i;
BZERO(buf, BUFSIZE);
for (i = arg; i < argcnt; i++) {
if (no_options && STRNEQ(args[i], "-"))
continue;
strcat(buf, args[i]);
strcat(buf, " ");
}
return(strip_ending_whitespace(buf));
}
If this debug patch is added you can see it:
…--- tools.c 2018-11-16 14:39:48.962081275 -0500
+++ tools.c 2019-01-24 11:50:26.408509742 -0500
@@ -1567,12 +1567,13 @@ concat_args(char *buf, int arg, int no_o
BZERO(buf, BUFSIZE);
for (i = arg; i < argcnt; i++) {
+fprintf(fp, "args[%d]: [%s]\n", i, args[i]);
if (no_options && STRNEQ(args[i], "-"))
continue;
strcat(buf, args[i]);
strcat(buf, " ");
}
-
+fprintf(fp, "concat_args: [%s]\n", buf);
return(strip_ending_whitespace(buf));
}
Normally expressions encompassed by parentheses get passed as single argument:
crash> p (3 - 1)
args[0]: [p]
args[1]: [(3 - 1)]
concat_args: [p (3 - 1) ]
$3 = 2
crash>
But in this case, it's being broken up:
crash> p (((uint)((struct sk_buff*)0xffff880311e08000)->tail) - ((uint)((struct sk_buff*)0xffff880311e08000)->data))
args[0]: [p]
args[1]: [(((uint)((struct]
args[2]: [sk_buff*)0xffff880311e08000)->tail)]
args[3]: [-]
args[4]: [((uint)((struct]
args[5]: [sk_buff*)0xffff880311e08000)->data))]
concat_args: [p (((uint)((struct sk_buff*)0xffff880311e08000)->tail) ((uint)((struct sk_buff*)0xffff880311e08000)->data)) ]
You can't do that without a process to debug.
p: gdb request failed: p (((uint)((struct sk_buff*)0xffff880311e08000)->tail) ((uint)((struct sk_buff*)0xffff880311e08000)->data))
crash>
So it goes back to the original call from process_command_line()
to parse_line(), which is getting confused by the multiple parentheses
in the expression. The "expression" variable in parse_line() should
probably be a counter instead of a boolean or something like that,
but I'm hesitant to screw around with it since it's such a commonly-called
function.
Better to use "gdb" as you have, or "p ($39 - $40)".
Dave
|
|
----- Original Message -----
----- Original Message -----
> As I am able to evaluate two values (casting pointers to `uint`s) - I
> should
> be able to figure out the distance between said pointers (note - don't want
> pointer math)
>
> As can be seen I can evaluate each cated-pointer as can be seen in `$39` &
> `$40`
> but when i try to evaluate/print the byte-delta between those `crash`
> reports
> an error from ``gdb`, but if i force it into `gdb` as can be seen in the
> last line it just works. So looks like something in the `crash`
> command-line processing is eating up the `-` (minus)
>
>
> ```
> crash> p ((uint)((struct sk_buff*)0xe47d9900)->tail)
> $39 = 3778076956
> crash> p ((uint)((struct sk_buff*)0xe47d9900)->data)
> $40 = 3778076872
> crash> p (((uint)((struct sk_buff*)0xe47d9900)->tail) - ((uint)((struct
> sk_buff*)0xe47d9900)->data))
> You can't do that without a process to debug.
> p: gdb request failed: p (((uint)((struct sk_buff*)0xe47d9900)->tail)
> ((uint)((struct sk_buff*)0xe47d9900)->data))
> crash> gdb p (((uint)((struct sk_buff*)0xe47d9900)->tail) - ((uint)((struct
> sk_buff*)0xe47d9900)->data))
> $41 = 84
> ```
Yeah, the call from cmp_p() to concat_args() is purposefully extracting it.
/*
* Concatenates the tokens in the global args[] array into one string,
* separating each token with one space. If the no_options flag is set,
* don't include any args beginning with a dash character.
*/
char *
concat_args(char *buf, int arg, int no_options)
{
int i;
BZERO(buf, BUFSIZE);
for (i = arg; i < argcnt; i++) {
if (no_options && STRNEQ(args[i], "-"))
continue;
strcat(buf, args[i]);
strcat(buf, " ");
}
return(strip_ending_whitespace(buf));
}
If this debug patch is added you can see it:
--- tools.c 2018-11-16 14:39:48.962081275 -0500
+++ tools.c 2019-01-24 11:50:26.408509742 -0500
@@ -1567,12 +1567,13 @@ concat_args(char *buf, int arg, int no_o
BZERO(buf, BUFSIZE);
for (i = arg; i < argcnt; i++) {
+fprintf(fp, "args[%d]: [%s]\n", i, args[i]);
if (no_options && STRNEQ(args[i], "-"))
continue;
strcat(buf, args[i]);
strcat(buf, " ");
}
-
+fprintf(fp, "concat_args: [%s]\n", buf);
return(strip_ending_whitespace(buf));
}
Normally expressions encompassed by parentheses get passed as single
argument:
crash> p (3 - 1)
args[0]: [p]
args[1]: [(3 - 1)]
concat_args: [p (3 - 1) ]
$3 = 2
crash>
But in this case, it's being broken up:
crash> p (((uint)((struct sk_buff*)0xffff880311e08000)->tail) -
((uint)((struct sk_buff*)0xffff880311e08000)->data))
args[0]: [p]
args[1]: [(((uint)((struct]
args[2]: [sk_buff*)0xffff880311e08000)->tail)]
args[3]: [-]
args[4]: [((uint)((struct]
args[5]: [sk_buff*)0xffff880311e08000)->data))]
concat_args: [p (((uint)((struct sk_buff*)0xffff880311e08000)->tail)
((uint)((struct sk_buff*)0xffff880311e08000)->data)) ]
You can't do that without a process to debug.
p: gdb request failed: p (((uint)((struct
sk_buff*)0xffff880311e08000)->tail) ((uint)((struct
sk_buff*)0xffff880311e08000)->data))
crash>
So it goes back to the original call from process_command_line()
to parse_line(), which is getting confused by the multiple parentheses
in the expression. The "expression" variable in parse_line() should
probably be a counter instead of a boolean or something like that,
but I'm hesitant to screw around with it since it's such a commonly-called
function.
Better to use "gdb" as you have, or "p ($39 - $40)".
Dave
On the other hand, I don't recall why cmd_p() is setting the "no_options" flag
to TRUE? There must have been a reason, but I don't recall why. Hmmm...
Dave
|
|
----- Original Message -----
...
On the other hand, I don't recall why cmd_p() is setting the "no_options" flag
to TRUE? There must have been a reason, but I don't recall why. Hmmm...
No, I don't believe there ever was a reason. Just removed it:
977c3a2
Fix for the "p" command if the expression contains more than one
opening parenthesis character and a minus/dash sign. Without the
patch, the minus/dash sign will get dropped from the command prior
to it being passed on to gdb for evaluation, and the command will
fail with the message "p: gdb request failed: <expression>",
where the <expression> string will not contain the minus/dash sign.
([email protected])
Thanks,
Dave
|
|
Works! thanks Dave |
bjoto
pushed a commit
to bjoto/crash
that referenced
this issue
Nov 2, 2022
1. Add riscv64_init() implementation, do all necessary machine-specific setup, which will be called multiple times during initialization. 2. Add riscv64 sv39/48/57 pagetable macro definitions, the function of converting virtual address to a physical address via 4K page table. For 2M and 1G pagesize, they will be implemented in the future(currently not supported). 3. Add the implementation of the vtop command, which is used to convert a virtual address to a physical address(call the functions defined in 2). 4. Add the implementation to get virtual memory layout, va_bits, phys_ram_base from vmcoreinfo. As these configurations changes from time to time, we send a Linux kernel patch to export these configurations, which can simplify the development of crash tool. The Linux patch (patch 5 of the patch set): https://lore.kernel.org/linux-riscv/[email protected]/ 5. Add riscv64_get_smp_cpus() implementation, get the number of cpus. 6. Add riscv64_get_page_size() implementation, get page size. And so on. With this patch, we can enter crash command line, and run "vtop", "mod", "rd", "*", "p", "kmem" ... Tested on QEMU RISCV64 end and SoC platform of T-head Xuantie 910 CPU. KERNEL: vmlinux DUMPFILE: vmcore CPUS: 1 DATE: Fri Jul 15 10:24:25 CST 2022 UPTIME: 00:00:33 LOAD AVERAGE: 0.05, 0.01, 0.00 TASKS: 41 NODENAME: buildroot RELEASE: 5.18.9 VERSION: crash-utility#30 SMP Fri Jul 15 09:47:03 CST 2022 MACHINE: riscv64 (unknown Mhz) MEMORY: 1 GB PANIC: "Kernel panic - not syncing: sysrq triggered crash" PID: 113 COMMAND: "sh" TASK: ff60000002269600 [THREAD_INFO: ff60000002269600] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> p mem_map mem_map = $1 = (struct page *) 0xff6000003effbf00 crash> p /x *(struct page *) 0xff6000003effbf00 $5 = { flags = 0x1000, { { { lru = { next = 0xff6000003effbf08, prev = 0xff6000003effbf08 }, { __filler = 0xff6000003effbf08, mlock_count = 0x3effbf08 } }, mapping = 0x0, index = 0x0, private = 0x0 }, crash> mod MODULE NAME BASE SIZE OBJECT FILE ffffffff0113e740 nvme_core ffffffff01133000 98304 (not loaded) [CONFIG_KALLSYMS] ffffffff011542c0 nvme ffffffff0114c000 61440 (not loaded) [CONFIG_KALLSYMS] crash> rd ffffffff0113e740 8 ffffffff0113e740: 0000000000000000 ffffffff810874f8 .........t...... ffffffff0113e750: ffffffff011542c8 726f635f656d766e .B......nvme_cor ffffffff0113e760: 0000000000000065 0000000000000000 e............... ffffffff0113e770: 0000000000000000 0000000000000000 ................ crash> vtop ffffffff0113e740 VIRTUAL PHYSICAL ffffffff0113e740 8254d740 PGD: ffffffff810e9ff8 => 2ffff001 P4D: 0000000000000000 => 000000002fffec01 PUD: 00005605c2957470 => 0000000020949801 PMD: 00007fff7f1750c0 => 0000000020947401 PTE: 0 => 209534e7 PAGE: 000000008254d000 PTE PHYSICAL FLAGS 209534e7 8254d000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY) PAGE PHYSICAL MAPPING INDEX CNT FLAGS ff6000003f0777d8 8254d000 0 0 1 0 Tested-by: Yixun Lan <[email protected]> Signed-off-by: Xianting Tian <[email protected]>
k-hagio
pushed a commit
that referenced
this issue
Dec 22, 2022
1. Add riscv64_init() implementation, do all necessary machine-specific setup,
which will be called multiple times during initialization.
2. Add riscv64 sv39/48/57 pagetable macro definitions, the function of converting
virtual address to a physical address via 4K page table.
For 2M and 1G pagesize, they will be implemented in the future(currently not supported).
3. Add the implementation of the vtop command, which is used to convert a
virtual address to a physical address(call the functions defined in 2).
4. Add the implementation to get virtual memory layout, va_bits, phys_ram_base
from vmcoreinfo. As these configurations changes from time to time, we sent
a Linux kernel patch to export these configurations, which can simplify the
development of crash tool.
The kernel commit: 649d6b1019a2 ("RISC-V: Add arch_crash_save_vmcoreinfo")
5. Add riscv64_get_smp_cpus() implementation, get the number of cpus.
6. Add riscv64_get_page_size() implementation, get page size.
And so on.
With this patch, we can enter crash command line, and run "vtop", "mod", "rd",
"*", "p", "kmem" ...
Tested on QEMU RISCV64 end and SoC platform of T-head Xuantie 910 CPU.
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 1
DATE: Fri Jul 15 10:24:25 CST 2022
UPTIME: 00:00:33
LOAD AVERAGE: 0.05, 0.01, 0.00
TASKS: 41
NODENAME: buildroot
RELEASE: 5.18.9
VERSION: #30 SMP Fri Jul 15 09:47:03 CST 2022
MACHINE: riscv64 (unknown Mhz)
MEMORY: 1 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 113
COMMAND: "sh"
TASK: ff60000002269600 [THREAD_INFO: ff60000002269600]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> p mem_map
mem_map = $1 = (struct page *) 0xff6000003effbf00
crash> p /x *(struct page *) 0xff6000003effbf00
$5 = {
flags = 0x1000,
{
{
{
lru = {
next = 0xff6000003effbf08,
prev = 0xff6000003effbf08
},
{
__filler = 0xff6000003effbf08,
mlock_count = 0x3effbf08
}
},
mapping = 0x0,
index = 0x0,
private = 0x0
},
crash> mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffff0113e740 nvme_core ffffffff01133000 98304 (not loaded) [CONFIG_KALLSYMS]
ffffffff011542c0 nvme ffffffff0114c000 61440 (not loaded) [CONFIG_KALLSYMS]
crash> rd ffffffff0113e740 8
ffffffff0113e740: 0000000000000000 ffffffff810874f8 .........t......
ffffffff0113e750: ffffffff011542c8 726f635f656d766e .B......nvme_cor
ffffffff0113e760: 0000000000000065 0000000000000000 e...............
ffffffff0113e770: 0000000000000000 0000000000000000 ................
crash> vtop ffffffff0113e740
VIRTUAL PHYSICAL
ffffffff0113e740 8254d740
PGD: ffffffff810e9ff8 => 2ffff001
P4D: 0000000000000000 => 000000002fffec01
PUD: 00005605c2957470 => 0000000020949801
PMD: 00007fff7f1750c0 => 0000000020947401
PTE: 0 => 209534e7
PAGE: 000000008254d000
PTE PHYSICAL FLAGS
209534e7 8254d000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ff6000003f0777d8 8254d000 0 0 1 0
Tested-by: Yixun Lan <[email protected]>
Signed-off-by: Xianting Tian <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As I am able to evaluate two values (casting pointers to
uints) - I should be able to figure out the distance between said pointers (note - don't want pointer math)As can be seen I can evaluate each cated-pointer as can be seen in
$39&$40but when i try to evaluate/print the byte-delta between those
crashreports an error fromgdb, but if I force it intogdbas can be seen in the last line it just works. So looks like something in thecrashcommand-line processing is eating up the-(minus)The text was updated successfully, but these errors were encountered: