Re: problem with kgdb and modules. (k)gdb expert needed.

on 05/02/2012 09:58 Julian Elischer said the following:
> In 9.x ( can't check -current, but teh mailing list has a better readership)
> 
> I'm still seeing this and have still not found any solution:
> possible reasons for the change may be:
> 1/ change to kgdb?
> 2/ change to the compiling toolset?
> 3/ change to the .mk files for compiling modules?
> 
> any guidance would be appreciated..
> The reason I can get away with using FreeBSD ar work is because I can debug
> modules well
> as in Linux this is generally a problem.. Now I see similar breakage in
> freebsd.  (sigh)).
> 
> I really don't know where to start looking for this..

Julian,

just in case, how about some basic stuff like checking that the modules are
indeed built with debugging support, that .symbols are installed and are
accessible, that kgdb produces those messages: "Reading symbols", "Loaded symbols".

> On 2/3/12 11:55 PM, Julian Elischer wrote:
>> so We upgraded our development machines from 8 stable to 9 stable. and now
>> kgdb can't debug inside modules.
>>
>> instead of getting anything useful, we just get:
>>
>> (kgdb) bt
>> #0  0xffffffff81814600 in ?? () from /boot/kernel/netgraph.ko
>> #1  0xffffffff81812d80 in ?? () from /boot/kernel/ng_socket.ko
>> #2  0x0000000000000037 in ?? ()
>> #3  0x0000000000000002 in ?? ()
>> #4  0xfffffe0007176aa0 in ?? ()
>> #5  0xfffffe0007176aa0 in ?? ()
>> #6  0xffffffff818134a0 in ?? () from /boot/kernel/ng_socket.ko
>> #7  0xffffffff81813960 in ?? () from /boot/kernel/ng_socket.ko
>> #8  0xffffff860fa3cad0 in ?? ()
>> #9  0xffffffff808cc76e in socreate (dom=Variable "dom" is not available.
>> ) at ../../../kern/uipc_socket.c:411
>>
>>
>>
>> but stopping in the kernel itself, we DO see stuff..
>>
>> (kgdb) break socreate
>> Breakpoint 1 at 0xffffffff808cc628: file ../../../kern/uipc_socket.c, line 372.
>> (kgdb) c
>> Continuing.
>>
>>
>>
>> [New Thread 100198]
>> [Switching to Thread 100198]
>>
>> Breakpoint 1, socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1,
>> cred=0xfffffe000c63f600, td=0xfffffe011501a000) at
>> ../../../kern/uipc_socket.c:372
>> 372             if (proto)
>> (kgdb) bt
>> #0  socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1,
>> cred=0xfffffe000c63f600, td=0xfffffe011501a000) at
>> ../../../kern/uipc_socket.c:372
>> #1  0xffffffff808cf710 in sys_socket (td=0xfffffe011501a000,
>> uap=0xffffff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199
>> #2  0xffffffff80b5599a in amd64_syscall (td=0xfffffe011501a000, traced=0) at
>> subr_syscall.c:131
>> #3  0xffffffff80b40b57 in Xfast_syscall () at
>> ../../../amd64/amd64/exception.S:387
>> #4  0x00000008011c82ac in ?? ()
>>
>>
>>
>> etc.
>>
>> it looks as if modules no longer have stack frames compiled in.
>> does anyone know the culprit?
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>>
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Andriy Gapon