----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility