[Crash-utility] Getting dissassembly from .o or .ko file

[Dave Anderson]

----- Original Message -----
> 
> Hello,
> 
> I have a kernel panic that prints a backtrace, but no kernel dump.
> The lines in the backtrace has the usual format:
> 
> [<addr1>] ? func1+num1/num2 [module1]
> 
> I understand that num1 is the address offset from the beginning of
> func1. What is num2?

The num2 value is the size in bytes of the whole function.

> 
> I tried to narrow down the location in func1() by doing the following
> steps:
> 
> loaded file1.o file into gdb and issued a "disassemble func1".
> The disassembled version of func1, the lines pertaining to function
> calls in func1() has the following format:
> 
> ...............callq num3 <func1+num4> <====
> 
> And NOT the following format I am used to:
> 
> .................callq <addr2> <func2>
> (func2 is a function called from within func1)
> 
> My question is related to line marked with <====
> 
> - Looking closely as the values of num3 and num4, the instruction
> seems to point to a location somewhere in func1 itself, and not the
> called function- func2. I must be reading the instruction wrong? How
> does one interpret the "calls" instruction.

No, you are reading the instruction correctly.  (unresolved)   

> - I understand I can't get something like addr2 in the line marked
> with <==== as the object file is not linked to the kernel. However,
> is there any way or tools I can use so the function name shows up in
> the the line <====. That would make it easier for me to understand
> the disassembled code.
> 
> Using gdb on the kernel module (*.ko) did not make a difference in
> the disassemble output.

You might try the "list" command to show "what's around" a particular
address.

Taking this simple example, if you want to know what function is being
called from nfs_cache_destroy+9:

 (gdb) disass nfs_cache_destroy
 Dump of assembler code for function nfs_cache_destroy:
    0x0000000000016750 <+0>:	callq  0x16755 <nfs_cache_destroy+5>
    0x0000000000016755 <+5>:	push   %rbp
    0x0000000000016756 <+6>:	mov    %rsp,%rbp
    0x0000000000016759 <+9>:	callq  0x1675e <nfs_cache_destroy+14>
    0x000000000001675e <+14>:	pop    %rbp
    0x000000000001675f <+15>:	retq   
 End of assembler dump.
 (gdb)

Pass the address that is performing the callq to the list
command like this:

 (gdb) list *0x0000000000016759
 0x16759 is in nfs_cache_destroy (fs/nfs/cache_lib.c:164).
 159		sunrpc_init_cache_detail(cd);
 160	}
 161	
 162	void nfs_cache_destroy(struct cache_detail *cd)
 163	{
 164		sunrpc_destroy_cache_detail(cd);
 165	}
 (gdb)

And it's obvious in this case that it's calling sunrpc_destroy_cache_detail().
 
Dave