Re: [Crash-utility] Getting dissassembly from .o or .ko file
----- 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