given a makedumpfile processed coredump, generate a symbolic backtrace containing the same info as a standard gdb backtrace
6:06 p.m.
Hi all,
I've got a coredump file processed by makedumpfile (non-elf) and am
trying to get a backtrace with all the line numbers, argument values,
and argument types like a normal gdb backtrace with debug info (yes, I
have a vmlinux built with debuginfo).
gdb refuses to load the core dump (no big supprise there). crash loads
it but it's builtin backtrace doesn't appear to use debug info, and as a
result doesn't give me arguments + types. Doing "gdb bt" complains about
not having a stack.
Any advise? I see a few paths forward:
- somehow get crash's gdb to understand where the stack is
- hack gdb to load the non-elf coredump
- modify makedumpfile to allow it to convert the non-elf coredump back
to elf.
Thanks.
10:21 p.m.
Crash's bt command doesn't provide function arguments/types as part of the
backtrace (use bt not gdb's bt). There's an extension module here that may provide
what you want:
http://people.redhat.com/anderson/extensions.html#FP
There a lot of history on the mailing list about wanting to use gdb's bt command if
you want to have a read of it.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of Cody P Schafer
Sent: Tuesday, September 10, 2013 9:07 AM
To: crash-utility(a)redhat.com; kexec(a)lists.infradead.org
Subject: [Crash-utility] given a makedumpfile processed coredump, generate a symbolic
backtrace containing the same info as a standard gdb backtrace
Hi all,
I've got a coredump file processed by makedumpfile (non-elf) and am trying to get a
backtrace with all the line numbers, argument values, and argument types like a normal gdb
backtrace with debug info (yes, I have a vmlinux built with debuginfo).
gdb refuses to load the core dump (no big supprise there). crash loads it but it's
builtin backtrace doesn't appear to use debug info, and as a result doesn't give
me arguments + types. Doing "gdb bt" complains about not having a stack.
Any advise? I see a few paths forward:
- somehow get crash's gdb to understand where the stack is
- hack gdb to load the non-elf coredump
- modify makedumpfile to allow it to convert the non-elf coredump back to elf.
Thanks.
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:57 a.m.
----- Original Message -----
Crash's bt command doesn't provide function arguments/types
as part of the
backtrace (use bt not gdb's bt). There's an extension module here that may
provide what you want:
http://people.redhat.com/anderson/extensions.html#FP
There a lot of history on the mailing list about wanting to use gdb's bt
command if you want to have a read of it.
You got that right -- this post points to several earlier threads:
Re: [Crash-utility] Getting access to function parameters
https://www.redhat.com/archives/crash-utility/2012-December/msg00029.html
Dave
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Cody P Schafer
Sent: Tuesday, September 10, 2013 9:07 AM
To: crash-utility(a)redhat.com; kexec(a)lists.infradead.org
Subject: [Crash-utility] given a makedumpfile processed coredump, generate a
symbolic backtrace containing the same info as a standard gdb backtrace
Hi all,
I've got a coredump file processed by makedumpfile (non-elf) and am trying to
get a backtrace with all the line numbers, argument values, and argument
types like a normal gdb backtrace with debug info (yes, I have a vmlinux
built with debuginfo).
gdb refuses to load the core dump (no big supprise there). crash loads it but
it's builtin backtrace doesn't appear to use debug info, and as a result
doesn't give me arguments + types. Doing "gdb bt" complains about not
having
a stack.
Any advise? I see a few paths forward:
- somehow get crash's gdb to understand where the stack is
- hack gdb to load the non-elf coredump
- modify makedumpfile to allow it to convert the non-elf coredump back to
elf.
Thanks.
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
10:38 a.m.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Tuesday, September 10, 2013 8:57 AM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] given a makedumpfile processed coredump, generate
a symbolic backtrace containing the same info as a standard gdb backtrace
I had partial success at a crash extension that used DWARF debuginfo to display a symbolic
backtrace. You can find it at https://github.com/jhammond/xbt.
Best,
John
4:18 p.m.
On 09/10/2013 08:38 AM, Hammond, John wrote:
I had partial success at a crash extension that used DWARF debuginfo to display a
symbolic backtrace. You can find it at https://github.com/jhammond/xbt.
I noticed that when searching for a solution, but hadn't tried it until
seeing this email.
After trying it, the xbt appears incorrect: it traces through some
functions not shown by bt and only has 6 frames vs bt's 22.
I've pasted the output below:
----
crash> bt
PID: 12982 TASK: ffff8803c50b6100 CPU: 0 COMMAND: "flush-9:100"
#0 [ffff8803df6714c0] machine_kexec at ffffffff81027a50
#1 [ffff8803df671520] crash_kexec at ffffffff81088ffd
#2 [ffff8803df6715f0] oops_end at ffffffff810074d0
#3 [ffff8803df671620] no_context at ffffffff8102e983
#4 [ffff8803df671670] __bad_area_nosemaphore at ffffffff8102ec05
#5 [ffff8803df6716c0] bad_area_nosemaphore at ffffffff8102ecce
#6 [ffff8803df6716d0] do_page_fault at ffffffff8102f1c8
#7 [ffff8803df6717e0] page_fault at ffffffff813be61f
[exception RIP: __bio_add_page+264]
RIP: ffffffff8114b818 RSP: ffff8803df671890 RFLAGS: 00010246
RAX: 0000000000040000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 0000000000000000 RSI: ffff880467e1df20 RDI: ffff88046c07fa00
RBP: ffff880300000001 R8: 0000000000000001 R9: 0000000000000000
R10: 0000000000000008 R11: 0000000000000001 R12: ffff880400000000
R13: 0000000000001000 R14: ffffea000d425170 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffff8803df6718f8] bio_add_page at ffffffff8114b971
#9 [ffff8803df671908] __mpage_writepage at ffffffff81150840
#10 [ffff8803df671a58] write_cache_pages at ffffffff810d6c09
#11 [ffff8803df671b88] mpage_writepages at ffffffff81150dd9
#12 [ffff8803df671bc8] _nzt_writepages at ffffffffa0183280 [nztmpfs]
#13 [ffff8803df671bd8] do_writepages at ffffffff810d6f4c
#14 [ffff8803df671be8] writeback_single_inode at ffffffff8113f5e9
#15 [ffff8803df671c28] writeback_sb_inodes at ffffffff8113ff18
#16 [ffff8803df671c88] writeback_inodes_wb at ffffffff8114062a
#17 [ffff8803df671cd8] wb_writeback at ffffffff811409db
#18 [ffff8803df671dd8] wb_do_writeback at ffffffff81140c03
#19 [ffff8803df671e68] bdi_writeback_task at ffffffff81140ddb
#20 [ffff8803df671eb8] bdi_start_fn at ffffffff810e5571
#21 [ffff8803df671ee8] kthread at ffffffff8106a24e
#22 [ffff8803df671f48] kernel_thread at ffffffff81003d1a
crash> xbt
#0
mod NONE, name schedule, RIP 0xffffffff813bb56c
frame start 0xffff8803df671d80, end 0xffff8803df671d88, *base
0000000000000000
&prev = ffff8803df671c80
prev = ffff8803df671cd0 ...
&next = ffff8803df671c78
[... trimmed ...]
&next = ffff8803df671c78
next = ffff8803df671d20 ...
&prev = ffff8803df671c80
prev = ffff8803df671cd0 ...
#1
mod NONE, name thread_return, RIP 0xffffffff813bb5aa
frame start 0xffff8803df671d88, end 0xffff8803df671dd8, *base
0xffff8803df671e60
&prev = ffff8803df671cd0
prev = ffff8803df671dd0 ...
[... trimmed ...]
&prev = ffff8803df671cd0
prev = ffff8803df671dd0 ...
#2
mod NONE, name wb_do_writeback, RIP 0xffffffff81140c03
frame start 0xffff8803df671dd8, end 0xffff8803df671e68, *base
0xffff8803df671eb0
&force_wait = ffff8803df671dec
force_wait = ffff8803 ...
&work = ffff8803df671df8
work = ffff88045f6f97d8 ...
#3
mod NONE, name bdi_writeback_task, RIP 0xffffffff81140ddb
frame start 0xffff8803df671e68, end 0xffff8803df671eb8, *base
0xffff8803df671ee0
XBT_R12 = ffff88045f6f9760
XBT_R13 = ffff8803c50b6100
XBT_R14 = 10001ee46
XBT_R15 = 124f8
wb = ffff88045f6f9760
last_active = 10001ee46
#4
mod NONE, name bdi_start_fn, RIP 0xffffffff810e5571
frame start 0xffff8803df671eb8, end 0xffff8803df671ee8, *base
0xffff8803df671f40
XBT_R12 = ffff88045f6f9760
XBT_R13 = ffffffff810e54f0
XBT_R14 = ffff88045f6f97c0
XBT_R15 = ffff88046e4a9840
ptr = ffff88045f6f9760
wb = ffff88045f6f9760
#5
mod NONE, name kthread, RIP 0xffffffff8106a24e
frame start 0xffff8803df671ee8, end 0xffff8803df671f48, *base
0xffff88046e4b5f40
XBT_R12 = ffffffff810e5571
&self = ffff8803df671ee8
self = ffffffff8106a24e ...
x = ffff8803df671ef0
#6
mod NONE, name kernel_thread, RIP 0xffffffff81003d1a
frame start 0xffff8803df671f48, end 0xffff8803df671f48, *base
0xffff88046e4b5f40
3946
days inactive
3948
days old
devel@lists.crash-utility.osci.io
4 comments
4 participants
participants (4)
-
Cody P Schafer -
Dave Anderson -
Hammond, John -
Seymour, Shane M