Re: Oops stack trace missing function addresses
On Fri, Oct 16, 2020 at 2:49 PM Adrian Larumbe wrote: > > > OK, I'll bite. You *are* getting the function name and offset, what > > additional > > knowledge do you get from knowing the VA? > > I was hoping to use the VA to calculate the C source line where the > fault happens, by substracting the function's VA from the module load > address as revealed by cat /proc/modules, adding the offset within the > function and then passing the offset to addr2line. > > I've just realised I might as well load the module object file into gdb > and do 'info line *(func+offset)'. > > But how would I do this just with addr2line ? scripts/faddr2line path/to/module.ko symbol+0xsym_offset/0xsym_size would give you the C source line referenced by the offset. > > > What architecture is this on? Stack unwinding is architecture-dependent, so > > it may just be the unwinder for that arch doesn't output the virtual > > address. > > It's a QEMU VM, 'uname -m' claims it's i686. > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Oops stack trace missing function addresses
OK, I'll bite. You *are* getting the function name and offset, what additional knowledge do you get from knowing the VA? I was hoping to use the VA to calculate the C source line where the fault happens, by substracting the function's VA from the module load address as revealed by cat /proc/modules, adding the offset within the function and then passing the offset to addr2line. I've just realised I might as well load the module object file into gdb and do 'info line *(func+offset)'. But how would I do this just with addr2line ? What architecture is this on? Stack unwinding is architecture-dependent, so it may just be the unwinder for that arch doesn't output the virtual address. It's a QEMU VM, 'uname -m' claims it's i686. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Oops stack trace missing function addresses
On Thu, 15 Oct 2020 18:34:08 +0100, Adrian Larumbe said: > claims, I get no VA next to each function in the Call Trace: > > Call Trace: > do_one_initcall+0xfc/0x290 > ? cache_alloc_debugcheck_after+0x38/0x270 > ? rcu_read_lock_sched_held+0x77/0xa0 > ? kmem_cache_alloc_trace+0x2b6/0x330 > do_init_module+0x4b/0x1b6 > load_module+0x2140/0x24c0 OK, I'll bite. You *are* getting the function name and offset, what additional knowledge do you get from knowing the VA? What architecture is this on? Stack unwinding is architecture-dependent, so it may just be the unwinder for that arch doesn't output the virtual address. pgpJ89sdbw6JQ.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Oops stack trace missing function addresses
Hi everyone, I wrote a small kernel module where I trigger a page fault by writing to an invalid memory address. This causes an Oops that prints the associated Stack Trace, but contrary to what the kernel documentation claims, I get no VA next to each function in the Call Trace: Call Trace: do_one_initcall+0xfc/0x290 ? cache_alloc_debugcheck_after+0x38/0x270 ? rcu_read_lock_sched_held+0x77/0xa0 ? kmem_cache_alloc_trace+0x2b6/0x330 do_init_module+0x4b/0x1b6 load_module+0x2140/0x24c0 ? find_held_lock+0x2d/0xa0 sys_init_module+0xdd/0x100 do_int80_syscall_32+0x73/0x170 entry_INT80_32+0xcf/0xcf This looks very much unlike what I see in https://www.kernel.org/doc/html/v4.11/admin-guide/bug-hunting.html I was wondering maybe the reason is that I didn't compile the kernel with the right debug options, but a quick glance at the .config file reveals they all seem to be there: CONFIG_DEBUG_INFO=y CONFIG_STACKTRACE=y CONFIG_DEBUG_BUGVERBOSE=y Cheers, Adrian ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
