https://wiki.openvz.org/index.php?action=history&feed=atom&title=Disassembling_the_kernelDisassembling the kernel - Revision history2026-04-09T16:47:37ZRevision history for this page on the wikiMediaWiki 1.31.1https://wiki.openvz.org/index.php?title=Disassembling_the_kernel&diff=6354&oldid=prevXemul: Created2008-08-22T10:36:30Z<p>Created</p>
<p><b>New page</b></p><div>This page describes how to obtain sufficient disassembling of your kernel when reporting a new BUG caught on a self-compiled kernel.<br />
<br />
== The <code>objdump</code> utility ==<br />
<br />
The main utility used to do it is the <code>objdump</code> one. Most of the time it's enough just to run<br />
<pre><br />
# objdump -dr <the-binary-file-to-dump> > <the-output-file><br />
</pre><br />
and the disassembled binary will be obtained.<br />
<br />
Most often you'd need to provide the dump of the <code>vmlinu'''x'''</code> file like this:<br />
<pre><br />
# objdump -dr vmlinux-<kernel-version> > vmlinux.decoded<br />
</pre><br />
<br />
We'll need the <code>vmlinux.decoded</code> file in this case.<br />
<br />
== Some hints that can be get from the kernel BUG report ==<br />
<br />
Let's look at how a BUG report can look (in the <code>dmesg</code> output)<br />
<pre><br />
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000044<br />
printing eip:<br />
c05d575b<br />
*pde = 00000000<br />
Oops: 0000 [#1]<br />
SMP<br />
Modules linked in: ...<br />
...<br />
Call Trace:<br />
[<c0429ea3>] local_bh_enable+0x95/0xa4<br />
...<br />
[<c05bc1ba>] net_rx_action+0x8f/0x185<br />
[<c05b1aa9>] kernel_sendmsg+0x2f/0x3d<br />
[<d0a7e24f>] xs_send_kvec+0x92/0x9a [sunrpc]<br />
[<c048e3bc>] destroy_inode+0x24/0x33<br />
[<d0a7e38e>] xs_sendpages+0x82/0x128 [sunrpc]<br />
...<br />
[<d0a80732>] rpc_async_schedule+0x0/0x8 [sunrpc]<br />
[<c0433d6a>] run_workqueue+0x78/0xf5<br />
[<c0433de7>] worker_thread+0x0/0xdc<br />
...<br />
[<c04371fb>] kthread+0x0/0x55<br />
[<c0405913>] kernel_thread_helper+0x7/0x10<br />
=======================<br />
...<br />
EIP: [<c05d575b>] ip_route_output_slow+0x40/0x6fa SS:ESP 0068:cf73bbbc<br />
</pre><br />
<br />
I've thrown away some unneeded info, so as you can see some function names in the stack trace are accompanied with the <code>[sunrpc]</code> string. This is a module name, in you traces you can see some other modules. So, when you disassembled the <code>vmlinux</code> file and attached this to the BUG report, very likely we'll ask you to disassemble the modules, that are seen in the stack trace, so you'd have to run the<br />
<pre><br />
# objdump -dr /lib/modules/<version>/<path>/<module-name>.ko > <module-name>.decoded<br />
</pre><br />
command and attach this module dump as well. Note, that the string<br />
<pre><br />
EIP: [<c05d575b>] ip_route_output_slow+0x40/0x6fa SS:ESP 0068:cf73bbbc<br />
</pre><br />
also contains the function name, that can also belong to some module.<br />
<br />
[[Category:Kernel]]<br />
[[Category:HOWTO]]</div>Xemul