So now that I got ddb working good I went back and built kernel with KGDB options per the 'man KGDB' page. I followed the other steps and I have a null modem cable hooked up. When I run 'gdb bsd.gdb' on the control system and then 'target remote /dev/cua00', it does not break into debugger on the target system. Now that current kernel builds with KGDB option, is anyone using it?
Justin -----Original Message----- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Mayes Sent: Monday, December 24, 2012 11:07 AM To: Philip Guenther Cc: misc@openbsd.org Subject: Re: Kernel Debugging Your right. I can view that struct also. The other structs I tried must have been out of scope. Thanks for your help Philip. J -----Original Message----- From: Philip Guenther [mailto:guent...@gmail.com] Sent: Sunday, December 23, 2012 6:51 PM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: Kernel Debugging On Sun, Dec 23, 2012 at 1:34 PM, Justin Mayes <jma...@careered.com> wrote: > I was looking into kernel debug options and found that trying to build > a kernel with kgdb option enabled fails. If no one uses it, it won't keep working. Submitting a patch to fix the build would be a first step. I suggest trying it both with DDB and without DDB: those should both work. > Anyone using the kgdb setup? I can > use ddb it's just painful to have to manually walk structures to > examine values. I have moved on to plan B which was to build with > option DDB_STRUCT and the build is a success but the 'show struct' > command always returns 'unknown structure' for anything other than > mbuf. Anyone have any kernel debugging strategies they'd like to share? DDB_STRUCT works for me for other structures. For example, here's a session looking at a firefox struct proc: Stopped at Debugger+0x5: leave ddb{0}> ps/a PID COMMAND STRUCT PROC * UAREA * VMSPACE/VM_MAP 16253 firefox 0xfffffe812af09798 0xffff800032dd6000 0xfffffe81305ec1d0 8061 xpdf 0xfffffe81280e1a08 0xffff800032dfe000 0xfffffe81305ecd30 31009 firefox 0xfffffe81280e17a0 0xffff800032df9000 0xfffffe81305ec1d0 5390 firefox 0xfffffe81280e1c70 0xffff800032e0d000 0xfffffe81305ec1d0 10871 less 0xfffffe81280e1068 0xffff800032df4000 0xfffffe81305ece10 28672 vi 0xfffffe8129b0d7a8 0xffff800032e16000 0xfffffe81305ecb70 24081 firefox 0xfffffe81280e12d0 0xffff800032def000 0xfffffe81305ec1d0 29697 firefox 0xfffffe812af09c68 0xffff800032de5000 0xfffffe81305ec1d0 19401 firefox 0xfffffe812af09a00 0xffff800032de0000 0xfffffe81305ec1d0 27330 firefox 0xfffffe8135a2b4f0 0xffff800032ddb000 0xfffffe81305ec1d0 13735 firefox 0xfffffe812af09530 0xffff800032dd1000 0xfffffe81305ec1d0 819 firefox 0xfffffe812af092c8 0xffff800032dcc000 0xfffffe81305ec1d0 13812 firefox 0xfffffe812de71c60 0xffff800032dc2000 0xfffffe81305ec1d0 15769 firefox 0xfffffe812af09060 0xffff800032dc7000 0xfffffe81305ec1d0 2108 firefox 0xfffffe812de719f8 0xffff800032dbd000 0xfffffe81305ec1d0 7957 firefox 0xfffffe812de71790 0xffff800032db8000 0xfffffe81305ec1d0 20128 firefox 0xfffffe812de71528 0xffff800032db3000 0xfffffe81305ec1d0 4339 firefox 0xfffffe812de712c0 0xffff800032da6000 0xfffffe81305ec1d0 20161 firefox 0xfffffe812de71058 0xffff800032da1000 0xfffffe81305ec1d0 4258 firefox 0xfffffe812f591c58 0xffff800032d9c000 0xfffffe81305ec1d0 4495 firefox 0xfffffe812f5919f0 0xffff800032d8f000 0xfffffe81305ec1d0 ddb{0}> show struct proc 0xfffffe812af09798 struct proc at 0xfffffe812af09798 (616 bytes) p_runq 16 p_list 16 p_p 8 fffffe81368ad7c8 p_thr_link 16 p_fd 8 fffffe81377d1898 p_vmspace 8 fffffe81305ec1d0 p_sigacts 8 fffffe8136f246c0 p_exitsig 4 0 p_flag 4 4100080 p_spare 1 ef p_stat 1 3 p_pad1 1 af p_descfd 1 de p_pid 4 3f7d p_hash 16 p_dupfd 4 0 p_thrslpid 8 2309e1800 p_sigwait 4 0 p_estcpu 4 0 p_cpticks 4 0 p_pctcpu 4 0 p_wchan 8 fffffe812af09810 p_sleep_to 40 p_wmesg 8 ffffffff8083585c p_swtime 4 32 p_slptime 4 e p_cpu 8 ffff8000001c1000 p_ru 144 p_tu 40 p_rtime 16 p_uticks 4 0 p_sticks 4 0 p_iticks 4 0 p_systrace 8 0 p_siglist 4 0 p_textvp 8 fffffe812e522160 p_emuldata 8 0 p_sigdivert 4 0 p_sigmask 4 0 p_priority 1 32 p_usrpri 1 32 p_comm[17] 1 66 69 72 65 66 6f 78 0 0 0 0 0 0 0 0 0 0 p_emul 8 ffffffff80a4eb00 p_sigstk 24 p_sigcode 8 2034cd000 p_prof_addr 8 0 p_prof_ticks 8 0 p_addr 8 ffff800032dd6000 p_md 16 p_oldmask 4 deafbeef p_sigval 8 deafbeefdeafbeef p_sisig 4 deafbeef p_sicode 4 deafbeef p_sitrapno 8 deafbeefdeafbeef p_xstat 2 0 ddb{0}> As far as other random kernel debugging idea, I've occasionally added extra counters on code paths and then used "pstat -d d counter_name" to dump it from userspace, or circular buffers that the kernel snprintf()'s to and then dumped them with "pstat -d s buffer_name". I know some debug nasty low-level stuff using qemu or blochs to run the kernel in emulation where they can stop it and dump memory and register when it blows up. Philip Guenther [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
