<div dir="ltr"><div>Fantastic.  I liked how you used "objdump -r" to get the function call name.  I can do that on a system that does not have source code (specifially code related my loaded module) on it to narrow down the location of the panic.  I found the adding the "-d" in addition very helpful, "objdump -d -r <*.ko>"</div>

<div> </div><div>Thank you very much for taking time to respond to my questions in such detail, much appreciated.</div><div> </div><div>--Ahmed.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 2:05 PM, Dave Anderson <span dir="ltr"><<a href="mailto:anderson@redhat.com" target="_blank">anderson@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Another way to determine what's being called is to dump<br>
the relocation information.  Again, in the nfs_cache_destroy()<br>
function below, there are two callq instructions, one at<br>
the very beginning of the function at 0x0000000000016750,<br>
and the other one at 0x0000000000016759:<br>
<div class="im"><br>
 (gdb) disass nfs_cache_destroy<br>
 Dump of assembler code for function nfs_cache_destroy:<br>
    0x0000000000016750 <+0>:    callq  0x16755 <nfs_cache_destroy+5><br>
    0x0000000000016755 <+5>:    push   %rbp<br>
    0x0000000000016756 <+6>:    mov    %rsp,%rbp<br>
    0x0000000000016759 <+9>:    callq  0x1675e <nfs_cache_destroy+14><br>
    0x000000000001675e <+14>:   pop    %rbp<br>
    0x000000000001675f <+15>:   retq<br>
 End of assembler dump.<br>
 (gdb)<br>
<br>
</div>The callq instructions consist of a one-byte "e8" opcode<br>
followed by 4 bytes of relative displacement, so in the<br>
example above, those 4 bytes would be located at addresses<br>
0x0000000000016751 and 0x000000000001675a respectively.<br>
(i.e., the callq site plus 1)<br>
<br>
So then if you dump the relocation information from the<br>
object file, you can see that __fentry__() is called at the<br>
beginning of the function (generated by the ftrace facility,<br>
and appearing at the beginning of all functions if it's<br>
configured), but more importangly, sunrpc_destroy_cache_detail()<br>
is the target of the second callq:<br>
<br>
 $ objdump --reloc nfs.ko<br>
 ... [ cut ] ...<br>
 0000000000016741 R_X86_64_PC32     __fentry__-0x0000000000000004<br>
 000000000001674a R_X86_64_PC32     sunrpc_init_cache_detail-0x0000000000000004<br>
 0000000000016751 R_X86_64_PC32     __fentry__-0x0000000000000004<br>
 000000000001675a R_X86_64_PC32     sunrpc_destroy_cache_detail-0x0000000000000004<br>
 0000000000016761 R_X86_64_PC32     __fentry__-0x0000000000000004<br>
 0000000000016769 R_X86_64_32S      .data+0x0000000000000720<br>
 ...<br>
<br>
which is what the list command showed:<br>
<div class="im"><br>
 (gdb) list *0x0000000000016759<br>
 0x16759 is in nfs_cache_destroy (fs/nfs/cache_lib.c:164).<br>
 159            sunrpc_init_cache_detail(cd);<br>
 160    }<br>
 161<br>
 162    void nfs_cache_destroy(struct cache_detail *cd)<br>
 163    {<br>
 164            sunrpc_destroy_cache_detail(cd);<br>
 165    }<br>
 (gdb)<br>
<br>
</div>The ftrace-generated call to __fentry__() will never be shown in<br>
the text listing.<br>
<div class="HOEnZb"><div class="h5"><br>
Dave<br>
<br>
--<br>
Crash-utility mailing list<br>
<a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br>
</div></div></blockquote></div><br></div>