Re: problem with kgdb and modules

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?

very easy to duplicate;

load a module
set a brakepoint in the module,
make it go there and stop
switch to remote kgdb .
(.gdbinit has:
# firewire dconschat is listening here:
target remote localhost:2223
info sharedlibrary
sharedlibrary ${YOUR_SHARED_LIBRARY}
)

notice that backtrace in KGDB is now crappy, where it looks great in DDB


>
> _______________________________________________
> 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"
>