Mulyadi Santosa wrote:
On Monday 07 August 2006 08:47, Jim Cromie wrote:
Ive got an oops, which is heavy with <symbol-addres> + <hex/hex>
offsets?
inter dereference at virtual address 00000000
[ 120.532000] printing eip:
[ 120.536000] c016c499
The first column is not the symbol address, Jim. AFAIK, that is the time
printk took to display the strings.
Let me rephrase.
1st column is as you say.
The 3rd column has <function-name> +< offset to an instruction >
[ 120.540000] Call Trace:
[ 120.540000] [<c016c6ed>] sysfs_remove_file+0xd/0xf
[ 120.540000] [<c01e7bce>] device_remove_file+0x1c/0x27
[ 120.540000] [<c880c988>] nsc_gpio_sysfs_bits_fini+0x6e/0x79 [nsc_gpio]
[ 120.540000] [<c8811253>] pc8736x_gpio_cleanup+0x3b/0xe4 [pc8736x_gpio]
[ 120.540000] [<c0123760>] sys_delete_module+0x16c/0x19c
[ 120.540000] [<c0102607>] syscall_call+0x7/0xb
[ 120.540000] DWARF2 unwinder stuck at syscall_call+0x7/0xb
[ 120.540000] Leftover inexact backtrace:
Unfortunately, function-name + offset is not as helpfull
as it could be, cuz objdump prints file-relative addresses,
not function-relative ones.
00000205 <sysfs_remove_file>:
205: 55 push %ebp
206: 89 e5 mov %esp,%ebp
208: 8b 40 30 mov 0x30(%eax),%eax
20b: 8b 12 mov (%edx),%edx
20d: e8 fc ff ff ff call 20e <sysfs_remove_file+0x9>
212: 5d pop %ebp
213: c3 ret
So, what is sysfs_remove_file+0x9 ?
Casually, it looks like the call target,
but is probably a branch backwards of a few insns.
My x86 assembler-fu is non-existent,
but it seems the address to label correspondence
could be more obvious.
I guess this isnt a kernel Q any more,
except that a good answer improves tool usage for/by all knewbies.
thanks, hope that clarifies
-jimc
regards,
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
