----- Original Message -----
> We have sadump, and it can work when the OS is out of controll(
> for example: dead loop, dead lock). When we use sadump, some
> user application may be running, and the sp/ip is in user stack.
>
> We should deal with it like kvm dump.
The patch appears reasonable, with two minor exceptions.
This stanza is incorrect, because it restricts both "bt -t" and "bt -T":
@@ -2761,6 +2846,8 @@ x86_64_low_budget_back_trace_cmd(struct bt_info *bt_in)
ofp = fp;
if (bt->flags & BT_TEXT_SYMBOLS) {
+ if (bt->flags & BT_USER_SPACE)
+ return;
if (!(bt->flags & BT_TEXT_SYMBOLS_ALL))
fprintf(ofp, "%sSTART: %s%s at %lx\n",
space(VADDR_PRLEN > 8 ? 14 : 6),
There's no reason to restrict "bt -T", because it's certainly possible
that a user may want to examine the kernel stack contents as they were
during the most recent entry into kernel-space:
-T display all text symbols found from just above the task_struct or
thread_info to the top of the stack. (helpful if the back trace
fails or the -t option starts too high in the process stack).
So I'll change it like this:
@@ -2761,6 +2846,9 @@
ofp = fp;
if (bt->flags & BT_TEXT_SYMBOLS) {
+ if ((bt->flags & BT_USER_SPACE) &&
+ !(bt->flags & BT_TEXT_SYMBOLS_ALL))
+ return;
if (!(bt->flags & BT_TEXT_SYMBOLS_ALL))
fprintf(ofp, "%sSTART: %s%s at %lx\n",
space(VADDR_PRLEN > 8 ? 14 : 6),
Also, you forgot to update dump_offset_table() in symbols.c
with all of the new user_regs_struct_xxx values for use
by "help -o".
I'll update dump_offset_table(), so you can consider the remainder
of the patch queued for the next release.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
