12:13 p.m.
- Enabled CONFIG_SPARSEMEM support for ia64 kernels; tested on
RHEL5-alpha (2.6.17-1.2519.4.5.el5). Without this fix, crash
would fail during initialization with error message indicating:
"crash: CONFIG_SPARSEMEM kernels not supported for this architecture"
(anderson(a)redhat.com, dwilder(a)us.ibm.com)
- Moved read_in_kernel_config() to just after the internal gdb
module gets initialized. Without this fix, xen kernels built
with CONFIG_IKCONFIG would fail during initialization indicating:
"crash: gdb_interface: gdb not initialized?"
(anderson(a)redhat.com, moriwaka(a)valinux.co.jp)
- Implemented new s390/s390x command "s390dbf" command to print out
kernel traces from the s390 debug feature (s390dbf). The debug
feature is an s390 kernel trace API which uses wraparound buffers
to store trace records in memory. Many of the s390 device drivers
use this feature. There is some documentation of the s390dbf in
the kernel sources under /Documentation/s390/s390dbf.txt.
(holzheu(a)de.ibm.com)
- RHEL5-alpha kernel modules (only x86_64 confirmed) may possibly
fail to be loaded with the "mod" command due to dwarf2 errors
associated with the the split module.ko/module.ko.debug debuginfo
facility used by RHEL kernels. Bugzillas have been filed to
address those problems, but the crash utility's error-reporting
mechanism has beem modified to properly reflect that the internal
gdb module has failed to load the kernel module's debug data.
Without this fix, the "mod -[sS]" commands would silently return
without loading the module data because the "add-symbol-file"
operation inside the gdb module failed, did a longjmp(), and ended
up back at the crash prompt. That behaviour has been changed
to report the module name and the gdb error like so:
crash> mod -S
mod: /lib/modules/2.6.17-1.2564.1/kernel/drivers/scsi/scsi_mod.ko
gdb add-symbol-file command failed
crash>
Note that this problem occurs in all post-RHEL4 kernels, i.e.,
FC4, FC5, and now FC6 and RHEL5.
(anderson(a)redhat.com)
- Fix for runaway unkillable "repeat" command output that can happen
when scrolling is turned off and the command that was entered is
bogus. (anderson(a)redhat.com)
- Fix for "struct structure.member address" output when the member
is an array; additional members beyond the array contents would
get displayed. (anderson(a)redhat.com)
- Fix to internal gdb module to properly handle relocatable kernel
virtual addresses; this will be required for upcoming relocatable
RHEL5 kernels required for the kexec/kdump facility.
(anderson(a)redhat.com)
- Combined kernel_init(PRE_GDB) and kernel_init(POST_GDB) into a
single call to kernel_init() that is done after gdb is initialized;
verify_version() now called by kernel_init(). This is just a code
re-work, and does not change any functionality. (anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
6:12 a.m.
New subject: [RFC] Patch to use gdb's bt in crash
Hi Dave
I was trying to implement better backtrace mechanism for crash using
dwarf info. And was trying to use the embedded gdb itself as gdb
already uses dwarf information for unwinding stack. I could get
"gdb bt" command working in "crash" after making one minor bug
fix in gdb_interface.c (Patch appended). Now one can get cleaner
backtrace particularly in x86_64 case using "gdb bt" command.
crash> bt
PID: 4146 TASK: ffff81022e848af0 CPU: 0 COMMAND: "insmod"
#0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
#1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
#2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
#3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
#4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
#5 [ffff81021efadd40] panic at ffffffff80131422
#6 [ffff81021efadda0] cond_resched at ffffffff804176c3
#7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
#8 [ffff81021efade00] __down_read at ffffffff80418d07
#9 [ffff81021efade30] fun2 at ffffffff80107017
#10 [ffff81021efade40] fun1 at ffffffff801311b6
#11 [ffff81021efade50] init_module at ffffffff8800200f
#12 [ffff81021efade60] sys_init_module at ffffffff8014c664
#13 [ffff81021efadf00] init_module at ffffffff88002068
#14 [ffff81021efadf80] system_call at ffffffff801096da
RIP: 00002b2153382d4a RSP: 00007fff57900a28 RFLAGS: 00010246
RAX: 00000000000000af RBX: ffffffff801096da RCX: 0000000000000000
RDX: 0000000000512010 RSI: 0000000000016d26 RDI: 00002b21531e5010
RBP: 00007fff57900c58 R8: 00002b21534f46d0 R9: 00002b21531fbd36
R10: 0000000000516040 R11: 0000000000000206 R12: 0000000000512010
R13: 00007fff579015c5 R14: 0000000000000000 R15: 00002b21531e5010
ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
crash> gdb bt 15
[Switching to thread 1 (process 4146)]#0 0xffffffff801521d1 in crash_kexec (regs=0x0) at
kexec.h:64
64 in kexec.h
#0 0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
#1 0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita triggering
panic\n") at kernel/panic.c:87
#2 0xffffffff80107017 in fun2 (i=0) at init/main.c:608
#3 0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
) at kernel/panic.c:278
#4 0xffffffff8800200f in ?? ()
#5 0xffffc2000023d9d0 in ?? ()
#6 0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400,
len=18446604445110683424,
uargs=0xffff81022ef6c6e8
"\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
at kernel/module.c:1911
#7 0xffffffff801096da in system_call () at bitops.h:230
#8 0x00002b2153382d4a in ?? ()
#9 0xffff81022e8516d0 in ?? ()
#10 0xffffffff8055c7c0 in migration_notifier ()
#11 0x0000000000000000 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
(More stack frames follow...)
crash>
===============================================================================
But as of now there are few issues with "gdb bt"
1) Sometimes the no. of stack frames displayed doesn't end for a long time
and also the "q" command doesn't work as desired once the screen is
full.
The workaround is to give some limiting count like "gdb bt 10".
I tried gdb ver 6.1 externally (outside crash) also and see the same
long ending stack frames where as the latest gdb (ver 6.4), works fine. So
just wondering if you are planning to upgrade embedded gdb to ver 6.4?
2) As unlike crash, there is no concept of tasks in gdb, we can only see the
backtraces for tasks active at the time of crash.
Apart from "bt" this change also allows to get some other related commands
like "gdb info registers", "gdb info frame" and "gdb info
threads" working.
Please let me know your comments about the approach.
Thanks
Rachita
o This patch fixes the broken crash-gdb interface for running gdb commands
in crash. Earlier the "argc" was not right and the commands to gdb used to
fail. The patch increments the argc correctly.
o This will particularly help in using the gdb backtrace mechanism for
active tasks at the point of crash. We now implicitly change the "thread"
id for gdb to the current context cpu before issuing the "bt" command to
embedded gdb.
Signed-off-by: Rachita Kothiyal <rachita(a)in.ibm.com>
---
gdb_interface.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff -puN gdb_interface.c~crash_use_gdb_bt gdb_interface.c
--- crash-4.0-3.1/gdb_interface.c~crash_use_gdb_bt 2006-08-24 15:21:22.527601072 +0530
+++ crash-4.0-3.1-rachita/gdb_interface.c 2006-08-24 15:51:51.314583192 +0530
@@ -58,6 +58,7 @@ gdb_main_loop(int argc, char **argv)
optind = 0;
command_loop_hook = main_loop;
+ argc ++;
#if defined(GDB_5_3) || defined(GDB_6_0) || defined(GDB_6_1)
gdb_main_entry(argc, argv);
@@ -670,6 +671,7 @@ void
cmd_gdb(void)
{
int c;
+ char *thread_cmd;
while ((c = getopt(argcnt, args, "")) != EOF) {
switch(c)
@@ -703,6 +705,18 @@ cmd_gdb(void)
whitespace(pc->orig_line[3]))
shift_string_left(pc->orig_line, strlen("gdb")+1);
+ /*
+ * If the request is a backtrace then switch context to
+ * current context in gdb too
+ */
+ if ((strncmp(clean_line(pc->orig_line), "backtrace", 9) == 0) ||
+ (strncmp(clean_line(pc->orig_line), "bt", 2) == 0)) {
+ thread_cmd = GETBUF(BUFSIZE);
+ sprintf(thread_cmd, "thread %d",
+ CURRENT_CONTEXT()->processor + 1);
+ gdb_pass_through(thread_cmd, NULL, 0);
+ FREEBUF(thread_cmd);
+ }
gdb_pass_through(clean_line(pc->orig_line), NULL, 0);
}
}
@@ -836,5 +850,3 @@ get_frame_offset(ulong pc)
"get_frame_offset: invalid request for non-alpha systems!\n"));
}
#endif /* !ALPHA */
-
-
_
8:15 a.m.
New subject: [RFC] Patch to use gdb's bt in crash
Rachita Kothiyal wrote:
Hi Dave
I was trying to implement better backtrace mechanism for crash using
dwarf info. And was trying to use the embedded gdb itself as gdb
already uses dwarf information for unwinding stack. I could get
"gdb bt" command working in "crash" after making one minor bug
fix in gdb_interface.c (Patch appended). Now one can get cleaner
backtrace particularly in x86_64 case using "gdb bt" command.
Wow -- your definition of "cleaner" apparently is different than mine... ;-)
crash> bt
PID: 4146 TASK: ffff81022e848af0 CPU: 0 COMMAND: "insmod"
#0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
#1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
#2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
#3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
#4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
#5 [ffff81021efadd40] panic at ffffffff80131422
#6 [ffff81021efadda0] cond_resched at ffffffff804176c3
#7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
#8 [ffff81021efade00] __down_read at ffffffff80418d07
#9 [ffff81021efade30] fun2 at ffffffff80107017
#10 [ffff81021efade40] fun1 at ffffffff801311b6
#11 [ffff81021efade50] init_module at ffffffff8800200f
#12 [ffff81021efade60] sys_init_module at ffffffff8014c664
#13 [ffff81021efadf00] init_module at ffffffff88002068
#14 [ffff81021efadf80] system_call at ffffffff801096da
RIP: 00002b2153382d4a RSP: 00007fff57900a28 RFLAGS: 00010246
RAX: 00000000000000af RBX: ffffffff801096da RCX: 0000000000000000
RDX: 0000000000512010 RSI: 0000000000016d26 RDI: 00002b21531e5010
RBP: 00007fff57900c58 R8: 00002b21534f46d0 R9: 00002b21531fbd36
R10: 0000000000516040 R11: 0000000000000206 R12: 0000000000512010
R13: 00007fff579015c5 R14: 0000000000000000 R15: 00002b21531e5010
ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
crash> gdb bt 15
[Switching to thread 1 (process 4146)]#0 0xffffffff801521d1 in crash_kexec (regs=0x0) at
kexec.h:64
64 in kexec.h
#0 0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
#1 0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita triggering
panic\n") at kernel/panic.c:87
#2 0xffffffff80107017 in fun2 (i=0) at init/main.c:608
#3 0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
) at kernel/panic.c:278
#4 0xffffffff8800200f in ?? ()
#5 0xffffc2000023d9d0 in ?? ()
#6 0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400,
len=18446604445110683424,
uargs=0xffff81022ef6c6e8
"\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
at kernel/module.c:1911
#7 0xffffffff801096da in system_call () at bitops.h:230
#8 0x00002b2153382d4a in ?? ()
#9 0xffff81022e8516d0 in ?? ()
#10 0xffffffff8055c7c0 in migration_notifier ()
#11 0x0000000000000000 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
(More stack frames follow...)
crash>
===============================================================================
But as of now there are few issues with "gdb bt"
1) Sometimes the no. of stack frames displayed doesn't end for a long time
and also the "q" command doesn't work as desired once the screen is
full.
The workaround is to give some limiting count like "gdb bt 10".
I tried gdb ver 6.1 externally (outside crash) also and see the same
long ending stack frames where as the latest gdb (ver 6.4), works fine. So
just wondering if you are planning to upgrade embedded gdb to ver 6.4?
Not really. That's a major undertaking with unpredictable results
until it's attempted. Every time I do that, nightmares follow, so only
if we get to the point where gdb-6.1 doesn't work at all, or cripples
crash's use of it with a new vmlinux, should we even think of doing that.
2) As unlike crash, there is no concept of tasks in gdb, we can only see the
backtraces for tasks active at the time of crash.
Apart from "bt" this change also allows to get some other related commands
like "gdb info registers", "gdb info frame" and "gdb info
threads" working.
Well, right off the bat, I'm not too keen on passing the vmcore to gdb,
because I don't know what the unseen ramifications of that would be.
Even so, you can't just do an "argc++" in gdb_main_loop() because
that apparently presumes that crash is receiving *only* two arguments,
in the "vmlinux vmcore" order. That cannot be presumed obviously,
as the possible combinations of crash command line options/ordering
are endless.
Secondly, until I see something useful in the case where the kernel
takes an in-kernel exception that in turn causes the crash, I'm
unconvinced. What does the trace look like if you take an
oops or BUG() while running in kernel mode? Does gdb step
past that point? (i.e., to the part of the backtrace we'd actually
want to see) Certainly we won't see a register dump at the exact
point of the exception. Would it make the jump from the x86_64
interrupt stack (or any of the exception stacks) back to the
process stack?
Given that it only gives backtraces of the active tasks, we're
still left with a half-baked implementation.
And now, with the introduction of the new CONFIG_UNWIND_INFO
and CONFIG_STACK_UNWIND configurations in the x86 and x86_64
kernels, wouldn't it make more sense to utilize the approach taken by
the crash-utility/ia64 unwind facility? Although the x86/x86_64
implementation still appears to be a work in progress in the kernel,
backporting that capability from the kernel to user-space would seem
to be more useful. That's what was done for ia64, and for that reason
it's the only architecture where we get dependable backtraces for
all tasks, active or not.
Simple question -- and to be quite honest with you -- I don't
understand why you wouldn't want to simply use gdb alone
in this case?
Dave
Please let me know your comments about the approach.
Thanks
Rachita
o This patch fixes the broken crash-gdb interface for running gdb commands
in crash. Earlier the "argc" was not right and the commands to gdb used to
fail. The patch increments the argc correctly.
o This will particularly help in using the gdb backtrace mechanism for
active tasks at the point of crash. We now implicitly change the "thread"
id for gdb to the current context cpu before issuing the "bt" command to
embedded gdb.
Signed-off-by: Rachita Kothiyal <rachita(a)in.ibm.com>
---
gdb_interface.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff -puN gdb_interface.c~crash_use_gdb_bt gdb_interface.c
--- crash-4.0-3.1/gdb_interface.c~crash_use_gdb_bt 2006-08-24 15:21:22.527601072
+0530
+++ crash-4.0-3.1-rachita/gdb_interface.c 2006-08-24 15:51:51.314583192 +0530
@@ -58,6 +58,7 @@ gdb_main_loop(int argc, char **argv)
optind = 0;
command_loop_hook = main_loop;
+ argc ++;
#if defined(GDB_5_3) || defined(GDB_6_0) || defined(GDB_6_1)
gdb_main_entry(argc, argv);
@@ -670,6 +671,7 @@ void
cmd_gdb(void)
{
int c;
+ char *thread_cmd;
while ((c = getopt(argcnt, args, "")) != EOF) {
switch(c)
@@ -703,6 +705,18 @@ cmd_gdb(void)
whitespace(pc->orig_line[3]))
shift_string_left(pc->orig_line, strlen("gdb")+1);
+ /*
+ * If the request is a backtrace then switch context to
+ * current context in gdb too
+ */
+ if ((strncmp(clean_line(pc->orig_line), "backtrace", 9) ==
0) ||
+ (strncmp(clean_line(pc->orig_line), "bt", 2) == 0)) {
+ thread_cmd = GETBUF(BUFSIZE);
+ sprintf(thread_cmd, "thread %d",
+ CURRENT_CONTEXT()->processor + 1);
+ gdb_pass_through(thread_cmd, NULL, 0);
+ FREEBUF(thread_cmd);
+ }
gdb_pass_through(clean_line(pc->orig_line), NULL, 0);
}
}
@@ -836,5 +850,3 @@ get_frame_offset(ulong pc)
"get_frame_offset: invalid request for non-alpha systems!\n"));
}
#endif /* !ALPHA */
-
-
_
11:20 a.m.
New subject: [RFC] Patch to use gdb's bt in crash
On Thu, Aug 24, 2006 at 09:15:34AM -0400, Dave Anderson wrote:
Rachita Kothiyal wrote:
> Hi Dave
>
> I was trying to implement better backtrace mechanism for crash using
> dwarf info. And was trying to use the embedded gdb itself as gdb
> already uses dwarf information for unwinding stack. I could get
> "gdb bt" command working in "crash" after making one minor bug
> fix in gdb_interface.c (Patch appended). Now one can get cleaner
> backtrace particularly in x86_64 case using "gdb bt" command.
>
Wow -- your definition of "cleaner" apparently is different than mine... ;-)
Looks are sometimes deceptive ;-).. Using gdb's stack winding code, the
unwanted stack frames (like frames # 4, 6, 7, 8) are avoided.
>
> crash> bt
> PID: 4146 TASK: ffff81022e848af0 CPU: 0 COMMAND: "insmod"
> #0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
> #1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
> #2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
> #3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
> #4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
> #5 [ffff81021efadd40] panic at ffffffff80131422
> #6 [ffff81021efadda0] cond_resched at ffffffff804176c3
> #7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
> #8 [ffff81021efade00] __down_read at ffffffff80418d07
> #9 [ffff81021efade30] fun2 at ffffffff80107017
> #10 [ffff81021efade40] fun1 at ffffffff801311b6
> #11 [ffff81021efade50] init_module at ffffffff8800200f
> #12 [ffff81021efade60] sys_init_module at ffffffff8014c664
> #13 [ffff81021efadf00] init_module at ffffffff88002068
> #14 [ffff81021efadf80] system_call at ffffffff801096da
> RIP: 00002b2153382d4a RSP: 00007fff57900a28 RFLAGS: 00010246
> RAX: 00000000000000af RBX: ffffffff801096da RCX: 0000000000000000
> RDX: 0000000000512010 RSI: 0000000000016d26 RDI: 00002b21531e5010
> RBP: 00007fff57900c58 R8: 00002b21534f46d0 R9: 00002b21531fbd36
> R10: 0000000000516040 R11: 0000000000000206 R12: 0000000000512010
> R13: 00007fff579015c5 R14: 0000000000000000 R15: 00002b21531e5010
> ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
> crash> gdb bt 15
> [Switching to thread 1 (process 4146)]#0 0xffffffff801521d1 in crash_kexec
(regs=0x0) at kexec.h:64
> 64 in kexec.h
> #0 0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
> #1 0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita triggering
panic\n") at kernel/panic.c:87
> #2 0xffffffff80107017 in fun2 (i=0) at init/main.c:608
> #3 0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
> ) at kernel/panic.c:278
> #4 0xffffffff8800200f in ?? ()
> #5 0xffffc2000023d9d0 in ?? ()
> #6 0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400,
len=18446604445110683424,
> uargs=0xffff81022ef6c6e8
"\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
> at kernel/module.c:1911
> #7 0xffffffff801096da in system_call () at bitops.h:230
> #8 0x00002b2153382d4a in ?? ()
> #9 0xffff81022e8516d0 in ?? ()
> #10 0xffffffff8055c7c0 in migration_notifier ()
> #11 0x0000000000000000 in ?? ()
> #12 0x0000000000000001 in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
> (More stack frames follow...)
> crash>
>
> ===============================================================================
>
> But as of now there are few issues with "gdb bt"
>
> 1) Sometimes the no. of stack frames displayed doesn't end for a long time
> and also the "q" command doesn't work as desired once the screen is
full.
> The workaround is to give some limiting count like "gdb bt 10".
> I tried gdb ver 6.1 externally (outside crash) also and see the same
> long ending stack frames where as the latest gdb (ver 6.4), works fine. So
> just wondering if you are planning to upgrade embedded gdb to ver 6.4?
>
Not really. That's a major undertaking with unpredictable results
until it's attempted. Every time I do that, nightmares follow, so only
if we get to the point where gdb-6.1 doesn't work at all, or cripples
crash's use of it with a new vmlinux, should we even think of doing that.
>
> 2) As unlike crash, there is no concept of tasks in gdb, we can only see the
> backtraces for tasks active at the time of crash.
>
>
> Apart from "bt" this change also allows to get some other related
commands
> like "gdb info registers", "gdb info frame" and "gdb info
threads" working.
>
Well, right off the bat, I'm not too keen on passing the vmcore to gdb,
because I don't know what the unseen ramifications of that would be.
Even so, you can't just do an "argc++" in gdb_main_loop() because
that apparently presumes that crash is receiving *only* two arguments,
in the "vmlinux vmcore" order. That cannot be presumed obviously,
as the possible combinations of crash command line options/ordering
are endless.
In anycase, currently gdb_main_loop() is not passing the right "argc"
to gdb.
Secondly, until I see something useful in the case where the kernel
takes an in-kernel exception that in turn causes the crash, I'm
unconvinced. What does the trace look like if you take an
oops or BUG() while running in kernel mode? Does gdb step
past that point? (i.e., to the part of the backtrace we'd actually
want to see) Certainly we won't see a register dump at the exact
point of the exception. Would it make the jump from the x86_64
interrupt stack (or any of the exception stacks) back to the
process stack?
Rachita, could you please test the patch which such dump also?
Given that it only gives backtraces of the active tasks, we're
still left with a half-baked implementation.
And now, with the introduction of the new CONFIG_UNWIND_INFO
and CONFIG_STACK_UNWIND configurations in the x86 and x86_64
kernels, wouldn't it make more sense to utilize the approach taken by
the crash-utility/ia64 unwind facility? Although the x86/x86_64
implementation still appears to be a work in progress in the kernel,
backporting that capability from the kernel to user-space would seem
to be more useful. That's what was done for ia64, and for that reason
it's the only architecture where we get dependable backtraces for
all tasks, active or not.
IIUC, this will involve writing dwarf support code for crash as a whole.
Simple question -- and to be quite honest with you -- I don't
understand why you wouldn't want to simply use gdb alone
in this case?
Instead of writing stack unwinding code using dwarf info from
scratch, gdb's code was re-used.
Thanks
Maneesh
12:41 p.m.
New subject: [RFC] Patch to use gdb's bt in crash
Maneesh Soni wrote:
On Thu, Aug 24, 2006 at 09:15:34AM -0400, Dave Anderson wrote:
> Rachita Kothiyal wrote:
>
> > Hi Dave
> >
> > I was trying to implement better backtrace mechanism for crash using
> > dwarf info. And was trying to use the embedded gdb itself as gdb
> > already uses dwarf information for unwinding stack. I could get
> > "gdb bt" command working in "crash" after making one minor
bug
> > fix in gdb_interface.c (Patch appended). Now one can get cleaner
> > backtrace particularly in x86_64 case using "gdb bt" command.
> >
>
> Wow -- your definition of "cleaner" apparently is different than mine...
;-)
>
Looks are sometimes deceptive ;-).. Using gdb's stack winding code, the
unwanted stack frames (like frames # 4, 6, 7, 8) are avoided.
> >
> > crash> bt
> > PID: 4146 TASK: ffff81022e848af0 CPU: 0 COMMAND: "insmod"
> > #0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
> > #1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
> > #2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
> > #3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
> > #4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
> > #5 [ffff81021efadd40] panic at ffffffff80131422
> > #6 [ffff81021efadda0] cond_resched at ffffffff804176c3
> > #7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
> > #8 [ffff81021efade00] __down_read at ffffffff80418d07
> > #9 [ffff81021efade30] fun2 at ffffffff80107017
> > #10 [ffff81021efade40] fun1 at ffffffff801311b6
> > #11 [ffff81021efade50] init_module at ffffffff8800200f
> > #12 [ffff81021efade60] sys_init_module at ffffffff8014c664
> > #13 [ffff81021efadf00] init_module at ffffffff88002068
> > #14 [ffff81021efadf80] system_call at ffffffff801096da
> > RIP: 00002b2153382d4a RSP: 00007fff57900a28 RFLAGS: 00010246
> > RAX: 00000000000000af RBX: ffffffff801096da RCX: 0000000000000000
> > RDX: 0000000000512010 RSI: 0000000000016d26 RDI: 00002b21531e5010
> > RBP: 00007fff57900c58 R8: 00002b21534f46d0 R9: 00002b21531fbd36
> > R10: 0000000000516040 R11: 0000000000000206 R12: 0000000000512010
> > R13: 00007fff579015c5 R14: 0000000000000000 R15: 00002b21531e5010
> > ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
Hmmm, and gdb frames #4 and #5 below are? I understand
that frames #8 through #14+ are probably gdb's ill-fated
attempt to understand what the entry-from-user-mode
exception frame is...
> > crash> gdb bt 15
> > [Switching to thread 1 (process 4146)]#0 0xffffffff801521d1 in crash_kexec
(regs=0x0) at kexec.h:64
> > 64 in kexec.h
> > #0 0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
> > #1 0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita
triggering panic\n") at kernel/panic.c:87
> > #2 0xffffffff80107017 in fun2 (i=0) at init/main.c:608
> > #3 0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
> > ) at kernel/panic.c:278
> > #4 0xffffffff8800200f in ?? ()
> > #5 0xffffc2000023d9d0 in ?? ()
> > #6 0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400,
len=18446604445110683424,
> > uargs=0xffff81022ef6c6e8
"\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
> > at kernel/module.c:1911
> > #7 0xffffffff801096da in system_call () at bitops.h:230
> > #8 0x00002b2153382d4a in ?? ()
> > #9 0xffff81022e8516d0 in ?? ()
> > #10 0xffffffff8055c7c0 in migration_notifier ()
> > #11 0x0000000000000000 in ?? ()
> > #12 0x0000000000000001 in ?? ()
> > #13 0xffffffffffffffff in ?? ()
> > #14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
> > (More stack frames follow...)
> > crash>
> >
> >
===============================================================================
> >
> > But as of now there are few issues with "gdb bt"
> >
> > 1) Sometimes the no. of stack frames displayed doesn't end for a long time
> > and also the "q" command doesn't work as desired once the
screen is full.
> > The workaround is to give some limiting count like "gdb bt 10".
> > I tried gdb ver 6.1 externally (outside crash) also and see the same
> > long ending stack frames where as the latest gdb (ver 6.4), works fine. So
> > just wondering if you are planning to upgrade embedded gdb to ver 6.4?
> >
>
> Not really. That's a major undertaking with unpredictable results
> until it's attempted. Every time I do that, nightmares follow, so only
> if we get to the point where gdb-6.1 doesn't work at all, or cripples
> crash's use of it with a new vmlinux, should we even think of doing that.
>
>
> >
> > 2) As unlike crash, there is no concept of tasks in gdb, we can only see the
> > backtraces for tasks active at the time of crash.
> >
> >
> > Apart from "bt" this change also allows to get some other related
commands
> > like "gdb info registers", "gdb info frame" and "gdb
info threads" working.
> >
>
> Well, right off the bat, I'm not too keen on passing the vmcore to gdb,
> because I don't know what the unseen ramifications of that would be.
> Even so, you can't just do an "argc++" in gdb_main_loop() because
> that apparently presumes that crash is receiving *only* two arguments,
> in the "vmlinux vmcore" order. That cannot be presumed obviously,
> as the possible combinations of crash command line options/ordering
> are endless.
>
In anycase, currently gdb_main_loop() is not passing the right "argc"
to gdb.
No actually it is doing the right thing currently; and it
would be OK with Rachita's patch if there were only two
command line args passed, specifically in the exact order,
"vmlinux vmcore".
The whole point is that crash's use of gdb was never
intended to pass it the vmcore file. gdb certainly won't
have a clue as to what to do with diskdump compressed-format
dumpfiles, xendump dumpfiles, xen "xm save" files, LKCD dumpfiles,
mcore dumpfiles, and will probably have issues with netdump and
diskdump vmcores for that matter -- since they don't save
the register sets of the non-panic cpus.
> Secondly, until I see something useful in the case where the kernel
> takes an in-kernel exception that in turn causes the crash, I'm
> unconvinced. What does the trace look like if you take an
> oops or BUG() while running in kernel mode? Does gdb step
> past that point? (i.e., to the part of the backtrace we'd actually
> want to see) Certainly we won't see a register dump at the exact
> point of the exception. Would it make the jump from the x86_64
> interrupt stack (or any of the exception stacks) back to the
> process stack?
>
Rachita, could you please test the patch which such dump also?
> Given that it only gives backtraces of the active tasks, we're
> still left with a half-baked implementation.
>
> And now, with the introduction of the new CONFIG_UNWIND_INFO
> and CONFIG_STACK_UNWIND configurations in the x86 and x86_64
> kernels, wouldn't it make more sense to utilize the approach taken by
> the crash-utility/ia64 unwind facility? Although the x86/x86_64
> implementation still appears to be a work in progress in the kernel,
> backporting that capability from the kernel to user-space would seem
> to be more useful. That's what was done for ia64, and for that reason
> it's the only architecture where we get dependable backtraces for
> all tasks, active or not.
>
IIUC, this will involve writing dwarf support code for crash as a whole.
Correct. And once it's done, we have the best
of all worlds.
> Simple question -- and to be quite honest with you -- I don't
> understand why you wouldn't want to simply use gdb alone
> in this case?
>
>
Instead of writing stack unwinding code using dwarf info from
scratch, gdb's code was re-used.
For that matter, if you really feel the need to jam
this into a crash session, why not just do this:
crash> !gdb vmlinux vmcore
...
[do whatever you want with (the latest-and-greatest) gdb]
...
(gdb) q
crash>
Thanks,
Dave
2:35 p.m.
New subject: [RFC] Patch to use gdb's bt in crash - works great with kgdb!
On Thu, 2006-08-24 at 09:15 -0400, Dave Anderson wrote:
Morning Dave:
Rachita Kothiyal wrote:
> Hi Dave
>
> I was trying to implement better backtrace mechanism for crash using
> dwarf info. And was trying to use the embedded gdb itself as gdb
> already uses dwarf information for unwinding stack. I could get
> "gdb bt" command working in "crash" after making one minor bug
> fix in gdb_interface.c (Patch appended). Now one can get cleaner
> backtrace particularly in x86_64 case using "gdb bt" command.
>
Wow -- your definition of "cleaner" apparently is different than mine... ;-)
>
> crash> bt
> PID: 4146 TASK: ffff81022e848af0 CPU: 0 COMMAND: "insmod"
> #0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
> #1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
> #2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
> #3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
> #4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
> #5 [ffff81021efadd40] panic at ffffffff80131422
> #6 [ffff81021efadda0] cond_resched at ffffffff804176c3
> #7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
> #8 [ffff81021efade00] __down_read at ffffffff80418d07
> #9 [ffff81021efade30] fun2 at ffffffff80107017
> #10 [ffff81021efade40] fun1 at ffffffff801311b6
> #11 [ffff81021efade50] init_module at ffffffff8800200f
> #12 [ffff81021efade60] sys_init_module at ffffffff8014c664
> #13 [ffff81021efadf00] init_module at ffffffff88002068
> #14 [ffff81021efadf80] system_call at ffffffff801096da
> RIP: 00002b2153382d4a RSP: 00007fff57900a28 RFLAGS: 00010246
> RAX: 00000000000000af RBX: ffffffff801096da RCX: 0000000000000000
> RDX: 0000000000512010 RSI: 0000000000016d26 RDI: 00002b21531e5010
> RBP: 00007fff57900c58 R8: 00002b21534f46d0 R9: 00002b21531fbd36
> R10: 0000000000516040 R11: 0000000000000206 R12: 0000000000512010
> R13: 00007fff579015c5 R14: 0000000000000000 R15: 00002b21531e5010
> ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
> crash> gdb bt 15
> [Switching to thread 1 (process 4146)]#0 0xffffffff801521d1 in crash_kexec
(regs=0x0) at kexec.h:64
> 64 in kexec.h
> #0 0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
> #1 0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita triggering
panic\n") at kernel/panic.c:87
> #2 0xffffffff80107017 in fun2 (i=0) at init/main.c:608
> #3 0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
> ) at kernel/panic.c:278
> #4 0xffffffff8800200f in ?? ()
> #5 0xffffc2000023d9d0 in ?? ()
> #6 0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400,
len=18446604445110683424,
> uargs=0xffff81022ef6c6e8
"\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
> at kernel/module.c:1911
> #7 0xffffffff801096da in system_call () at bitops.h:230
> #8 0x00002b2153382d4a in ?? ()
> #9 0xffff81022e8516d0 in ?? ()
> #10 0xffffffff8055c7c0 in migration_notifier ()
> #11 0x0000000000000000 in ?? ()
> #12 0x0000000000000001 in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
> (More stack frames follow...)
> crash>
>
> ===============================================================================
>
> But as of now there are few issues with "gdb bt"
>
> 1) Sometimes the no. of stack frames displayed doesn't end for a long time
> and also the "q" command doesn't work as desired once the screen is
full.
> The workaround is to give some limiting count like "gdb bt 10".
> I tried gdb ver 6.1 externally (outside crash) also and see the same
> long ending stack frames where as the latest gdb (ver 6.4), works fine. So
> just wondering if you are planning to upgrade embedded gdb to ver 6.4?
>
Not really. That's a major undertaking with unpredictable results
until it's attempted. Every time I do that, nightmares follow, so only
if we get to the point where gdb-6.1 doesn't work at all, or cripples
crash's use of it with a new vmlinux, should we even think of doing that.
>
> 2) As unlike crash, there is no concept of tasks in gdb, we can only see the
> backtraces for tasks active at the time of crash.
>
>
> Apart from "bt" this change also allows to get some other related
commands
> like "gdb info registers", "gdb info frame" and "gdb info
threads" working.
>
Well, right off the bat, I'm not too keen on passing the vmcore to gdb,
because I don't know what the unseen ramifications of that would be.
Even so, you can't just do an "argc++" in gdb_main_loop() because
that apparently presumes that crash is receiving *only* two arguments,
in the "vmlinux vmcore" order. That cannot be presumed obviously,
as the possible combinations of crash command line options/ordering
are endless.
Secondly, until I see something useful in the case where the kernel
takes an in-kernel exception that in turn causes the crash, I'm
unconvinced. What does the trace look like if you take an
oops or BUG() while running in kernel mode? Does gdb step
past that point? (i.e., to the part of the backtrace we'd actually
want to see) Certainly we won't see a register dump at the exact
point of the exception. Would it make the jump from the x86_64
interrupt stack (or any of the exception stacks) back to the
process stack?
Given that it only gives backtraces of the active tasks, we're
still left with a half-baked implementation.
And now, with the introduction of the new CONFIG_UNWIND_INFO
and CONFIG_STACK_UNWIND configurations in the x86 and x86_64
kernels, wouldn't it make more sense to utilize the approach taken by
the crash-utility/ia64 unwind facility? Although the x86/x86_64
implementation still appears to be a work in progress in the kernel,
backporting that capability from the kernel to user-space would seem
to be more useful. That's what was done for ia64, and for that reason
it's the only architecture where we get dependable backtraces for
all tasks, active or not.
Simple question -- and to be quite honest with you -- I don't
understand why you wouldn't want to simply use gdb alone
in this case?
I don't see any reason for core file not to be read correctly by
gdb. It's convenient to use gdb directly sometimes, for example
while using the ddd GUI.
kgdb isn't having any problems with kernel threads back traces.
The kernel objects are tweaked with dwarf code, but I see no
problem with using the same paradigm with crash. Works great.
I'd prefer to have crash and ddd+gdb operate on kernel core files.
Even better it would be nice to be able to simulate execution on
a stack of a core file to be able to re-execute code that caused
the crash. I frequently found it convenient after a panic to move
the pc to the end of panic, and continue back up the stack to a
break point at the system call. Then I'd use the GUI to move the
pc to before the execution of the system call and execute it again
and watch how the return value was derived that caused the panic.
I expect that if you run a kgdb kernel, including the drarf code,
that gdb will have no problem with core dumps. It's convenient to
have kgdb configured in the kernel and have the option to continue
analysis later with gdb/crash.
-piet
Dave
>
> Please let me know your comments about the approach.
>
> Thanks
> Rachita
>
> o This patch fixes the broken crash-gdb interface for running gdb commands
> in crash. Earlier the "argc" was not right and the commands to gdb
used to
> fail. The patch increments the argc correctly.
>
> o This will particularly help in using the gdb backtrace mechanism for
> active tasks at the point of crash. We now implicitly change the
"thread"
> id for gdb to the current context cpu before issuing the "bt" command
to
> embedded gdb.
>
> Signed-off-by: Rachita Kothiyal <rachita(a)in.ibm.com>
> ---
>
> gdb_interface.c | 16 ++++++++++++++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff -puN gdb_interface.c~crash_use_gdb_bt gdb_interface.c
> --- crash-4.0-3.1/gdb_interface.c~crash_use_gdb_bt 2006-08-24
15:21:22.527601072 +0530
> +++ crash-4.0-3.1-rachita/gdb_interface.c 2006-08-24 15:51:51.314583192 +0530
> @@ -58,6 +58,7 @@ gdb_main_loop(int argc, char **argv)
>
> optind = 0;
> command_loop_hook = main_loop;
> + argc ++;
>
> #if defined(GDB_5_3) || defined(GDB_6_0) || defined(GDB_6_1)
> gdb_main_entry(argc, argv);
> @@ -670,6 +671,7 @@ void
> cmd_gdb(void)
> {
> int c;
> + char *thread_cmd;
>
> while ((c = getopt(argcnt, args, "")) != EOF) {
> switch(c)
> @@ -703,6 +705,18 @@ cmd_gdb(void)
> whitespace(pc->orig_line[3]))
> shift_string_left(pc->orig_line,
strlen("gdb")+1);
>
> + /*
> + * If the request is a backtrace then switch context to
> + * current context in gdb too
> + */
> + if ((strncmp(clean_line(pc->orig_line), "backtrace", 9)
== 0) ||
> + (strncmp(clean_line(pc->orig_line), "bt", 2) == 0))
{
> + thread_cmd = GETBUF(BUFSIZE);
> + sprintf(thread_cmd, "thread %d",
> + CURRENT_CONTEXT()->processor + 1);
> + gdb_pass_through(thread_cmd, NULL, 0);
> + FREEBUF(thread_cmd);
> + }
> gdb_pass_through(clean_line(pc->orig_line), NULL, 0);
> }
> }
> @@ -836,5 +850,3 @@ get_frame_offset(ulong pc)
> "get_frame_offset: invalid request for non-alpha
systems!\n"));
> }
> #endif /* !ALPHA */
> -
> -
> _
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet(a)bluelane.com
H: (408) 243-8872; piet(a)piet.net
3:40 p.m.
New subject: [RFC] Patch to use gdb's bt in crash - works great with kgdb!
On Wed, Aug 30, 2006 at 12:35:21PM -0700, Piet Delaney wrote:
>
> Simple question -- and to be quite honest with you -- I don't
> understand why you wouldn't want to simply use gdb alone
> in this case?
I don't see any reason for core file not to be read correctly by
gdb. It's convenient to use gdb directly sometimes, for example
while using the ddd GUI.
You can run gdb to open core files as of today but the debugging
capability will be limited. For ex. kernel core headers have the info
of linearly mapped region only and they don't contain the virt address
info of non-linearly mapped regions. So one can not debug the non-linearly
mapped regions like modules.
kgdb isn't having any problems with kernel threads back traces.
The kernel objects are tweaked with dwarf code, but I see no
problem with using the same paradigm with crash. Works great.
Can you give some more details on what do you mean by kernel objects
are tweaked with dwarf code.
I'd prefer to have crash and ddd+gdb operate on kernel core
files.
You can already do that. Its just a matter of figuring out how to
get good backtraces both with "crash" as well as "gdb".
Even better it would be nice to be able to simulate execution on
a stack of a core file to be able to re-execute code that caused
the crash. I frequently found it convenient after a panic to move
the pc to the end of panic, and continue back up the stack to a
break point at the system call. Then I'd use the GUI to move the
pc to before the execution of the system call and execute it again
and watch how the return value was derived that caused the panic.
I expect that if you run a kgdb kernel, including the drarf code,
that gdb will have no problem with core dumps. It's convenient to
have kgdb configured in the kernel and have the option to continue
analysis later with gdb/crash.
Is kgdb mainline? I think some time back Andrew had dropped the patches
from -mm too. I don't know if distros carry kgdb or not? So not sure
for how many people will it be helpful to enable kgdb and then take
core dumps for better back traces.
I don't know much about tweaking objects with dwarf code but got a
general question. Why can't it be an independent patch in kernel
independent of kgdb. (If it helps in getting better backtraces.)
Thanks
Vivek
4:41 p.m.
New subject: [RFC] Patch to use gdb's bt in crash - works great with kgdb! - KGDB in Linus Kernel.
On Wed, 2006-08-30 at 16:40 -0400, Vivek Goyal wrote:
On Wed, Aug 30, 2006 at 12:35:21PM -0700, Piet Delaney wrote:
> >
> > Simple question -- and to be quite honest with you -- I don't
> > understand why you wouldn't want to simply use gdb alone
> > in this case?
>
> I don't see any reason for core file not to be read correctly by
> gdb. It's convenient to use gdb directly sometimes, for example
> while using the ddd GUI.
>
You can run gdb to open core files as of today but the debugging
capability will be limited. For ex. kernel core headers have the info
of linearly mapped region only and they don't contain the virt address
info of non-linearly mapped regions. So one can not debug the non-linearly
mapped regions like modules.
Amit's modified gdb might help for that problem. I haven't used
it but it allows gdb to load debug information about modules. You
can also use a script Amit wrote to explicitly load module info
into stock gdb; that also might work with kernel core files.
> kgdb isn't having any problems with kernel threads back traces.
> The kernel objects are tweaked with dwarf code, but I see no
> problem with using the same paradigm with crash. Works great.
>
Can you give some more details on what do you mean by kernel objects
are tweaked with dwarf code.
Attached is the cfi_annotations.patch patch from the kgdb-2.6.16 patch
which is part of the kgdb patch series. I believe George Anzinger used
a similar dwarf patch in the 2.6 mm series patches that Andrew provided.
I think Tom Rini wrote both of them.
> I'd prefer to have crash and ddd+gdb operate on kernel core files.
>
You can already do that. Its just a matter of figuring out how to
get good backtraces both with "crash" as well as "gdb".
I think Tom Rini's cfi_annotations could be a big part of that solution.
> Even better it would be nice to be able to simulate execution on
> a stack of a core file to be able to re-execute code that caused
> the crash. I frequently found it convenient after a panic to move
> the pc to the end of panic, and continue back up the stack to a
> break point at the system call. Then I'd use the GUI to move the
> pc to before the execution of the system call and execute it again
> and watch how the return value was derived that caused the panic.
>
> I expect that if you run a kgdb kernel, including the drarf code,
> that gdb will have no problem with core dumps. It's convenient to
> have kgdb configured in the kernel and have the option to continue
> analysis later with gdb/crash.
>
Is kgdb mainline? I think some time back Andrew had dropped the patches
from -mm too.
Yes, I think he had a number of issues with the kgdb patch but I can't
recall reading exactly what they are. One I believe is that the kgdb
patch should be completly non-invasive if not configured in. Currently
some files that are patched don't have #ifdef CONFIG_KGDB in them. I
noticed one last night while checking in some code.
I'd like to put those #ifdef's back in and make it part of the std
distribution. As I recall George Anzinger's patch had absolutely no
impact on the kernel if not configured in. Seems very important to me.
I don't know if distros carry kgdb or not? So not sure
for how many people will it be helpful to enable kgdb and then take
core dumps for better back traces.
More for larger servers like a Sun NUMA system. I'd find it convenient
to be able to go back a look at a crash of something that I looked at
previously. Might be good for bug reports to have references to core
files backing up a bug fix.
I don't know much about tweaking objects with dwarf code but got a
general question. Why can't it be an independent patch in kernel
independent of kgdb. (If it helps in getting better backtraces.)
Exactly. Locally I just checked in code that I expect will be useful for
kgdb or kdump. Stuff like compiling the kernel -O0 and converting
static inline functions to inline. Code to provide dwarf info and
save registers during a panic seem to also qualify.
My preference is for kgdb, like kexec, to become part of the
mainstream kernel as a configurable component. Perhaps Andrew
could enumerate his issues. It would make cooperation between
kgdb and crash a bit easier and make kernel debugging a lot
easier for the masses. Recent kgdb patches seem to be getting
much better.
-piet
Thanks
Vivek
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet(a)bluelane.com
H: (408) 243-8872; piet(a)piet.net
8:19 a.m.
New subject: [RFC] Patch to use gdb's bt in crash
On Thu, Aug 24, 2006 at 04:42:59PM +0530, Rachita Kothiyal wrote:
But as of now there are few issues with "gdb bt"
1) Sometimes the no. of stack frames displayed doesn't end for a long time
and also the "q" command doesn't work as desired once the screen is
full.
The workaround is to give some limiting count like "gdb bt 10".
I tried gdb ver 6.1 externally (outside crash) also and see the same
long ending stack frames where as the latest gdb (ver 6.4), works fine. So
just wondering if you are planning to upgrade embedded gdb to ver 6.4?
2) As unlike crash, there is no concept of tasks in gdb, we can only see the
backtraces for tasks active at the time of crash.
I guess, we will continue to have both the backtracing mechanisms. I am
assuming that this approach does not disable crash's bt mechanism. Its
kind of add on? So a user can use crash bt mechanism for backtraces of
tasks which are not currently running on some cpu.
Thanks
Vivek
8:26 a.m.
New subject: [RFC] Patch to use gdb's bt in crash
On Thu, Aug 24, 2006 at 09:19:49AM -0400, Vivek Goyal wrote:
On Thu, Aug 24, 2006 at 04:42:59PM +0530, Rachita Kothiyal wrote:
>
>
> But as of now there are few issues with "gdb bt"
>
> 1) Sometimes the no. of stack frames displayed doesn't end for a long time
> and also the "q" command doesn't work as desired once the screen is
full.
> The workaround is to give some limiting count like "gdb bt 10".
> I tried gdb ver 6.1 externally (outside crash) also and see the same
> long ending stack frames where as the latest gdb (ver 6.4), works fine. So
> just wondering if you are planning to upgrade embedded gdb to ver 6.4?
>
> 2) As unlike crash, there is no concept of tasks in gdb, we can only see the
> backtraces for tasks active at the time of crash.
I guess, we will continue to have both the backtracing mechanisms. I am
assuming that this approach does not disable crash's bt mechanism. Its
kind of add on? So a user can use crash bt mechanism for backtraces of
tasks which are not currently running on some cpu.
That's right Vivek. Crash bt is also available. So if you say 'bt'
on crash prompt you get the backtrace via crash, and if you say
'gdb bt' on crash prompt you will get the gdb backtrace.
Thanks
Rachita
6513
days inactive
6520
days old
devel@lists.crash-utility.osci.io
9 comments
5 participants
participants (5)
-
Dave Anderson -
Maneesh Soni -
Piet Delaney -
Rachita Kothiyal -
Vivek Goyal