Re: Kernel debugging
Daniel Hejduk writes: Is there any way to build the kernel on Linux preferably Arch Linux? In a VM, sure. Otherwise, no. Here's a comment from a thread about this topic, from a couple of years ago: https://www.reddit.com/r/openbsd/comments/r6wj3c/comment/hmwhk4a/ Alexis.
Re: Kernel debugging
On Sat, 11 May 2024 21:49:42 +0100, Daniel Hejduk wrote: > > Is there any way to build the kernel on Linux preferably Arch Linux? > It is theoretically possible, but you need to change Makefiles a lot, and probably to hack your toolchain. -- wbr, Kirill
Re: Kernel debugging
Hello again, Is there any way to build the kernel on Linux preferably Arch Linux? Best regards, Daniel Hejduk 11. května 2024 22:05:50 SELČ, "Kirill A. Korinsky" napsal: >On Sat, 11 May 2024 20:28:08 +0100, >Daniel Hejduk wrote: >> >> I want to enable kernel debugging how can I do it? >> > >See: https://man.openbsd.org/options > >-- >wbr, Kirill >
Re: Kernel debugging
> On 11 May 2024, at 22:28, Daniel Hejduk wrote: > > Hello, > I want to enable kernel debugging how can I do it? > See ddb(4) man page. > Best regards, > Daniel Hejduk
Re: Kernel debugging
On Sat, 11 May 2024 20:28:08 +0100, Daniel Hejduk wrote: > > I want to enable kernel debugging how can I do it? > See: https://man.openbsd.org/options -- wbr, Kirill
Kernel debugging
Hello, I want to enable kernel debugging how can I do it? Best regards, Daniel Hejduk
Re: Kernel debugging without serial port?
On 2021-05-19, Brennan Vincent wrote: > Hello, > > I have an x86_64 PC with no serial port - is it possible to run ddb > remotely via a PCI-express or USB serial port adapter? Or does it only > work on an actual motherboard serial port connection? It is sometimes possible via PCIE but you will need to set the io base address of the serial port manually with the "machine comaddr" boot loader commamd. And I think there are some cases whwre this doesn't work. > If not, how do most kernel developers do their development work? In VMs, > or on older hardware that actually does have a real serial port?: Various methods but machines with 'real' serial ports are definitely commonly used and sought after. Servers with serial-over-lan are sometimes used, as are standard consoles (ideally with important information transcribed when passing to others; screenshots maybe as a backup or for more detailed information).
Kernel debugging without serial port?
Hello, I have an x86_64 PC with no serial port - is it possible to run ddb remotely via a PCI-express or USB serial port adapter? Or does it only work on an actual motherboard serial port connection? If not, how do most kernel developers do their development work? In VMs, or on older hardware that actually does have a real serial port?:
My laptop brings to kernel debugging after closing lid.
Hi All/ My laptop brings to kernel debugging after closing-openning lid. orlov-nb$ uname -a OpenBSD orlov-nb.lan 6.9 GENERIC.MP#453 amd64 bios0: vendor Dell Inc. version "A16" date 05/24/2018 bios0: Dell Inc. Inspiron 3721 orlov-nb$ sysctl |grep machdep machdep.console_device=ttyC0 machdep.bios.diskinfo.128=bootdev = 0xa204, cylinders = 0, heads = 0, sectors = 0 machdep.bios.cksumlen=1 machdep.allowaperture=0 machdep.cpuvendor=GenuineIntel machdep.cpuid=0x306a9 machdep.cpufeature=0xbffbfbff machdep.kbdreset=0 machdep.xcrypt=0 machdep.lidaction=1 machdep.forceukbd=0 machdep.tscfreq=2494345791 machdep.invarianttsc=1 machdep.pwraction=1 what do you think is the reason for this? What additional information can I provide? -- Dmitry Orlov
Re: Kernel Debugging
Hi, I was debugging the OpenBSD kernel using Qemu and gdb. Well, it depends on the task. You can follow the below link if it suits to you and sees if it works for you. http://bijanebrahimi.github.io/blog/remote-debugging-the-running-openbsd-kernel.html In my case, I was debugging pledge(2) and also trying to see what happens in the kernel when one invokes any userspace command like "ls" from the command line. I created a demo system call to use it in debugging. So, it was easy for me to track the flow from user-space to kernels. If you put a breakpoint on some other syscall then it will create a noisy output every time when kernel boots up and maybe kernel panics (if you use lots of prints) While in FreeBSD, I have used a ddb kernel debugger for bug related stuff. And yeah, I think you have to compile it every time if you make any changes to the source code and want to see the change. Regards, Neeraj On Wed, 30 Oct, 2019, 2:12 am List, wrote: > Hi, > I was wondering how you guys debug your kernel? > Are you doing some vmd(8) voodoo ? > > Recompiling every time you think you've found the error gets quite > exhausting over time. > > g, > Stephan > >
Kernel Debugging
Hi, I was wondering how you guys debug your kernel? Are you doing some vmd(8) voodoo ? Recompiling every time you think you've found the error gets quite exhausting over time. g, Stephan
Re: Remote kernel debugging with kgdb and vmm
On Sun, 2018-05-13 at 22:22 +0300, IL Ka wrote: > AFAIK kgdb (remote debug) is not supported: > http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-debugging-tt > 335833.html#a341551 > > You can debug running kernel but functionality is limited. Thanks. Looks like using QEmu gdbserver[1] us my best option then. [1] https://bit.ly/2KYiTA4
Re: Remote kernel debugging with kgdb and vmm
AFAIK kgdb (remote debug) is not supported: http://openbsd-archive.7691.n7.nabble.com/on-line-kernel- debugging-tt335833.html#a341551 You can debug running kernel but functionality is limited.
Remote kernel debugging with kgdb and vmm
Hello, I'd like to dive into the bridge driver and I am trying to setup a kernel debugging environment. I chose to use VMM to do that but I don't seem to find a way to connect my local gdb to the VMM console. I guess I would need another serial device for KGDB, but I have not found how to do that in the man. Is anyone using VMM for this? Or plain old QEMU? Thanks, Xavier
on-line kernel debugging
Hi! does OpenBSD supports on-line kernel debugging as FreeBSD does[1]? The only tutorial I managed to find was a fairly old one[2] by QEMU over GNU/Linux but it seems kgdb(7) is removed since 6.2 (apparently for not even working before[3]). Thank you! [1]: https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html [2]: https://markshroyer.com/2013/01/debugging-openbsd-via-qemu/ [3]: https://github.com/openbsd/src/commits/master/sys/sys/kgdb.h
Re: Kernel Debugging
On 17:04 Mon 07 Jan , Justin Mayes wrote: I got this. I had 2 com ports on this old target desktop and when I switched the serial cable to the right one, it worked. I have working DDB kernel with structs as well as a working kgdb kernel with current. Justin Good. Any chance to get patches and kernel config from you?
Re: Kernel Debugging
Absolutely. Nothing custom, the build errors have all been fixed at least in CURRENT so I just had to get the kernel config right. Ddb and kgdb are mutually exclusive so your kernel must be built for one or the other. For ddb It's there by default in GENERIC, you just have to set sysctl machdep.kbdreset to 2 and reboot so you can break in with ctrl-alt-delete, see man ddb page. If you want to be able to parse structs easier add this to /usr/src/sys/conf/GENERIC and build new kernel Option DDB_STRUCT For kgdb Uncomment these options in /usr/src/sys/arch/i386/conf/GENERIC or make a different copy Option KGDB Option KGDB_DEVNAME=\com\,KGDBADDR=0x2f8,KGDBRATE=9600 Pay attention to the 0x2f8 there, you may need 0x3f8 to listen on com0 rather than com1 Run Dmesg | grep com to see Then in file /usr/src/sys/conf/GENERIC (or your debug copy) comment out the DDB stuff #option DDB #option DDB_SAFE_CONSOLE Uncomment Makeoptions DEBUG=-g Then build your kernel Comments and corrections are welcome. Justin -Original Message- From: sickm...@lavabit.com [mailto:sickm...@lavabit.com] Sent: Tuesday, January 08, 2013 6:44 AM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: Kernel Debugging On 17:04 Mon 07 Jan , Justin Mayes wrote: I got this. I had 2 com ports on this old target desktop and when I switched the serial cable to the right one, it worked. I have working DDB kernel with structs as well as a working kgdb kernel with current. Justin Good. Any chance to get patches and kernel config from you? [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Kernel Debugging
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 0xfe812af09798 0x800032dd6000
0xfe81305ec1d0
8061 xpdf0xfe81280e1a08 0x800032dfe000
0xfe81305ecd30
31009 firefox 0xfe81280e17a0 0x800032df9000
0xfe81305ec1d0
5390 firefox 0xfe81280e1c70 0x800032e0d000
0xfe81305ec1d0
10871 less0xfe81280e1068 0x800032df4000
0xfe81305ece10
28672 vi 0xfe8129b0d7a8 0x800032e16000
0xfe81305ecb70
24081 firefox 0xfe81280e12d0 0x800032def000
0xfe81305ec1d0
29697 firefox 0xfe812af09c68 0x800032de5000
0xfe81305ec1d0
19401 firefox 0xfe812af09a00 0x800032de
0xfe81305ec1d0
27330 firefox 0xfe8135a2b4f0 0x800032ddb000
0xfe81305ec1d0
13735 firefox 0xfe812af09530 0x800032dd1000
0xfe81305ec1d0
819 firefox 0xfe812af092c8 0x800032dcc000
0xfe81305ec1d0
13812 firefox 0xfe812de71c60 0x800032dc2000
0xfe81305ec1d0
15769 firefox 0xfe812af09060 0x800032dc7000
0xfe81305ec1d0
2108 firefox 0xfe812de719f8 0x800032dbd000
0xfe81305ec1d0
7957 firefox 0xfe812de71790 0x800032db8000
0xfe81305ec1d0
20128 firefox 0xfe812de71528 0x800032db3000
0xfe81305ec1d0
4339 firefox 0xfe812de712c0 0x800032da6000
0xfe81305ec1d0
20161 firefox 0xfe812de71058 0x800032da1000
0xfe81305ec1d0
4258 firefox 0xfe812f591c58 0x800032d9c000
0xfe81305ec1d0
4495 firefox 0xfe812f5919f0 0x800032d8f000
0xfe81305ec1d0
ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd 8 fe81377d1898
p_vmspace 8 fe81305ec1d0
p_sigacts 8 fe8136f246c0
p_exitsig 40
p_flag 4 4100080
p_spare1 ef
p_stat 13
p_pad1 1 af
p_descfd 1 de
p_pid 4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait 40
p_estcpu 40
p_cpticks 40
p_pctcpu 40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime 4 32
p_slptime 4e
p_cpu 8
Re: Kernel Debugging
I got this. I had 2 com ports on this old target desktop and when I switched
the serial cable to the right one, it worked. I have working DDB kernel with
structs as well as a working kgdb kernel with current.
Justin
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Monday, January 07, 2013 2:35 PM
To: misc@openbsd.org
Subject: Re: Kernel Debugging
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 0xfe812af09798 0x800032dd6000
0xfe81305ec1d0
8061 xpdf0xfe81280e1a08 0x800032dfe000
0xfe81305ecd30
31009 firefox 0xfe81280e17a0 0x800032df9000
0xfe81305ec1d0
5390 firefox 0xfe81280e1c70 0x800032e0d000
0xfe81305ec1d0
10871 less0xfe81280e1068 0x800032df4000
0xfe81305ece10
28672 vi 0xfe8129b0d7a8 0x800032e16000
0xfe81305ecb70
24081 firefox 0xfe81280e12d0 0x800032def000
0xfe81305ec1d0
29697 firefox 0xfe812af09c68 0x800032de5000
0xfe81305ec1d0
19401 firefox 0xfe812af09a00 0x800032de
0xfe81305ec1d0
27330 firefox 0xfe8135a2b4f0 0x800032ddb000
0xfe81305ec1d0
13735 firefox 0xfe812af09530 0x800032dd1000
0xfe81305ec1d0
819 firefox 0xfe812af092c8 0x800032dcc000
0xfe81305ec1d0
13812 firefox 0xfe812de71c60 0x800032dc2000
0xfe81305ec1d0
15769 firefox 0xfe812af09060 0x800032dc7000
0xfe81305ec1d0
2108 firefox 0xfe812de719f8 0x800032dbd000
0xfe81305ec1d0
7957 firefox 0xfe812de71790 0x800032db8000
0xfe81305ec1d0
20128 firefox 0xfe812de71528 0x800032db3000
0xfe81305ec1d0
4339 firefox 0xfe812de712c0 0x800032da6000
0xfe81305ec1d0
20161 firefox 0xfe812de71058 0x800032da1000
0xfe81305ec1d0
4258 firefox 0xfe812f591c58 0x800032d9c000
0xfe81305ec1d0
4495 firefox 0xfe812f5919f0 0x800032d8f000
0xfe81305ec1d0
ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd 8 fe81377d1898
p_vmspace 8 fe81305ec1d0
p_sigacts 8 fe8136f246c0
p_exitsig 40
p_flag 4 4100080
p_spare1 ef
p_stat 13
p_pad1 1 af
p_descfd 1 de
p_pid 4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait 40
p_estcpu
Re: Kernel Debugging
On Wed, Dec 26, 2012 at 5:32 PM, Luis Useche use...@gmail.com wrote: I just tried today and I couldn't build it either. But the following simple patch fixed it for me: ... However this might be wrong. Most likely there is a good reason why that ifdef is there. Well, does the resulting kernel run? Can it be debugged with a remote gdb? Can the in-kernel ddb still be used? Philip Guenther
Re: Kernel Debugging
I just tried today and I couldn't build it either. But the following simple patch fixed it for me: diff --git a/sys/ddb/db_run.c b/sys/ddb/db_run.c index 8b64fa3..825b72e 100644 --- a/sys/ddb/db_run.c +++ b/sys/ddb/db_run.c @@ -51,8 +51,6 @@ db_breakpoint_t db_taken_bkpt = 0; intdb_inst_count; -#ifndef KGDB - #include ddb/db_lex.h #include ddb/db_watch.h #include ddb/db_output.h @@ -298,7 +296,6 @@ db_continue_cmd(db_expr_t addr, int have_addr, db_expr_t count, char *modif) db_cmd_loop_done = 1; } -#endif /* NO KGDB */ #ifdef SOFTWARE_SSTEP /* However this might be wrong. Most likely there is a good reason why that ifdef is there. Luis On Mon, Dec 24, 2012 at 5:40 AM, sickm...@lavabit.com wrote: On 15:34 Sun 23 Dec , Justin Mayes wrote: I was looking into kernel debug options and found that trying to build a kernel with kgdb option enabled fails. 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? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] I gave it a try about a year ago, but not much luck. If you want to use gdb, you'll have either to fix kgdb or to run openbsd inside qemu and use qemu as a gdb backend. And you can always stick to ddb.
Re: Kernel Debugging
On 15:34 Sun 23 Dec , Justin Mayes wrote: I was looking into kernel debug options and found that trying to build a kernel with kgdb option enabled fails. 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? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] I gave it a try about a year ago, but not much luck. If you want to use gdb, you'll have either to fix kgdb or to run openbsd inside qemu and use qemu as a gdb backend. And you can always stick to ddb.
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 0xfe812af09798 0x800032dd6000
0xfe81305ec1d0
8061 xpdf0xfe81280e1a08 0x800032dfe000
0xfe81305ecd30
31009 firefox 0xfe81280e17a0 0x800032df9000
0xfe81305ec1d0
5390 firefox 0xfe81280e1c70 0x800032e0d000
0xfe81305ec1d0
10871 less0xfe81280e1068 0x800032df4000
0xfe81305ece10
28672 vi 0xfe8129b0d7a8 0x800032e16000
0xfe81305ecb70
24081 firefox 0xfe81280e12d0 0x800032def000
0xfe81305ec1d0
29697 firefox 0xfe812af09c68 0x800032de5000
0xfe81305ec1d0
19401 firefox 0xfe812af09a00 0x800032de
0xfe81305ec1d0
27330 firefox 0xfe8135a2b4f0 0x800032ddb000
0xfe81305ec1d0
13735 firefox 0xfe812af09530 0x800032dd1000
0xfe81305ec1d0
819 firefox 0xfe812af092c8 0x800032dcc000
0xfe81305ec1d0
13812 firefox 0xfe812de71c60 0x800032dc2000
0xfe81305ec1d0
15769 firefox 0xfe812af09060 0x800032dc7000
0xfe81305ec1d0
2108 firefox 0xfe812de719f8 0x800032dbd000
0xfe81305ec1d0
7957 firefox 0xfe812de71790 0x800032db8000
0xfe81305ec1d0
20128 firefox 0xfe812de71528 0x800032db3000
0xfe81305ec1d0
4339 firefox 0xfe812de712c0 0x800032da6000
0xfe81305ec1d0
20161 firefox 0xfe812de71058 0x800032da1000
0xfe81305ec1d0
4258 firefox 0xfe812f591c58 0x800032d9c000
0xfe81305ec1d0
4495 firefox 0xfe812f5919f0 0x800032d8f000
0xfe81305ec1d0
ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd 8 fe81377d1898
p_vmspace 8 fe81305ec1d0
p_sigacts 8 fe8136f246c0
p_exitsig 40
p_flag 4 4100080
p_spare1 ef
p_stat 13
p_pad1 1 af
p_descfd 1 de
p_pid 4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait 40
p_estcpu 40
p_cpticks 40
p_pctcpu 40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime 4 32
p_slptime 4e
p_cpu 8 801c1000
p_ru 144
p_tu 40
p_rtime16
p_uticks 40
p_sticks 40
p_iticks 40
p_systrace 80
p_siglist 40
p_textvp 8 fe812e522160
p_emuldata 80
p_sigdivert40
p_sigmask 40
p_priority
Kernel Debugging
I was looking into kernel debug options and found that trying to build a kernel with kgdb option enabled fails. 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? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
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 0xfe812af09798 0x800032dd6000 0xfe81305ec1d0
8061 xpdf0xfe81280e1a08 0x800032dfe000 0xfe81305ecd30
31009 firefox 0xfe81280e17a0 0x800032df9000 0xfe81305ec1d0
5390 firefox 0xfe81280e1c70 0x800032e0d000 0xfe81305ec1d0
10871 less0xfe81280e1068 0x800032df4000 0xfe81305ece10
28672 vi 0xfe8129b0d7a8 0x800032e16000 0xfe81305ecb70
24081 firefox 0xfe81280e12d0 0x800032def000 0xfe81305ec1d0
29697 firefox 0xfe812af09c68 0x800032de5000 0xfe81305ec1d0
19401 firefox 0xfe812af09a00 0x800032de 0xfe81305ec1d0
27330 firefox 0xfe8135a2b4f0 0x800032ddb000 0xfe81305ec1d0
13735 firefox 0xfe812af09530 0x800032dd1000 0xfe81305ec1d0
819 firefox 0xfe812af092c8 0x800032dcc000 0xfe81305ec1d0
13812 firefox 0xfe812de71c60 0x800032dc2000 0xfe81305ec1d0
15769 firefox 0xfe812af09060 0x800032dc7000 0xfe81305ec1d0
2108 firefox 0xfe812de719f8 0x800032dbd000 0xfe81305ec1d0
7957 firefox 0xfe812de71790 0x800032db8000 0xfe81305ec1d0
20128 firefox 0xfe812de71528 0x800032db3000 0xfe81305ec1d0
4339 firefox 0xfe812de712c0 0x800032da6000 0xfe81305ec1d0
20161 firefox 0xfe812de71058 0x800032da1000 0xfe81305ec1d0
4258 firefox 0xfe812f591c58 0x800032d9c000 0xfe81305ec1d0
4495 firefox 0xfe812f5919f0 0x800032d8f000 0xfe81305ec1d0
ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd 8 fe81377d1898
p_vmspace 8 fe81305ec1d0
p_sigacts 8 fe8136f246c0
p_exitsig 40
p_flag 4 4100080
p_spare1 ef
p_stat 13
p_pad1 1 af
p_descfd 1 de
p_pid 4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait 40
p_estcpu 40
p_cpticks 40
p_pctcpu 40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime 4 32
p_slptime 4e
p_cpu 8 801c1000
p_ru 144
p_tu 40
p_rtime16
p_uticks 40
p_sticks 40
p_iticks 40
p_systrace 80
p_siglist 40
p_textvp 8 fe812e522160
p_emuldata 80
p_sigdivert40
p_sigmask 40
p_priority 1 32
p_usrpri 1 32
p_comm[17] 1 66 69 72 65 66 6f 7800
00000000
p_emul 8 80a4eb00
Re: kernel debugging broken in 4.4-CURRENT?
Peter Kay - Syllopsium [EMAIL PROTECTED] writes: Given that I'm in a minority of kgdb users, what's everyone else using in cases like this? I use printfs, pstat -d and ddb. Never use breakpoints since I don't trust them, they mess up timing too much. //art
kernel debugging broken in 4.4-CURRENT?
Kgdb kernel debugging appears to have been broken in 4.4-CURRENT for a week if not longer. The exact same config file works creating a debug kernel under 4.3. I've updated kernel, userland etc. The same thing happens under every virtualised environment I throw it at (vmware, qemu, virtualbox). I get : 'com0: at isa0 port 0x3f8/8 irq 4panic: com_isa_attach: mapping failed ' followed by a kernel panic. In 4.3 it correctly refers to 'pccom' and says that kgdb has been attached. I can't be the only one needing to do kernel debugging with 4.4-CURRENT - am I missing something? kernel config file is : include arch/i386/conf/GENERIC rmoption DDB makeoptions DEBUG=-g option KGDB option KGDB_DEVNAME=\com\,KGDBADDR=0x3f8,KGDBRATE=9600 PK
Re: kernel debugging broken in 4.4-CURRENT?
On Tue, Oct 7, 2008 at 9:43 AM, Peter Kay - Syllopsium [EMAIL PROTECTED] wrote: Kgdb kernel debugging appears to have been broken in 4.4-CURRENT for a week if not longer. The exact same config file works creating a debug kernel under 4.3. I've updated kernel, userland etc. The same thing happens under every virtualised environment I throw it at (vmware, qemu, virtualbox). I get : 'com0: at isa0 port 0x3f8/8 irq 4panic: com_isa_attach: mapping failed ' followed by a kernel panic. In 4.3 it correctly refers to 'pccom' and says that kgdb has been attached. I can't be the only one needing to do kernel debugging with 4.4-CURRENT - am I missing something? You might be the only one using kgdb. Between 4.3 and 4.4 the pccom device was folded into com, which may not have gone perfectly.
Re: kernel debugging broken in 4.4-CURRENT?
From: Ted Unangst [EMAIL PROTECTED] To: Peter Kay - Syllopsium [EMAIL PROTECTED] You might be the only one using kgdb. Between 4.3 and 4.4 the pccom device was folded into com, which may not have gone perfectly. OK. A further question, then. What I'm trying to do is debug if_bridge and if_pppoe as I'm stupid enough to try hacking the source to bridge PPPoE(4) to another interface (it doesn't work, and if you hack if_bridge to tell it to add it to the bridge, the bridging doesn't work). if_bridge and if_pppoe are both kernel level files, and I want to set breakpoints to find out where it is/isn't working, so kgdb seemed like the best thing to use. Given that I'm in a minority of kgdb users, what's everyone else using in cases like this? PK
Re: kernel debugging broken in 4.4-CURRENT?
On Tue, Oct 7, 2008 at 11:36 AM, Peter Kay - Syllopsium [EMAIL PROTECTED] wrote: if_bridge and if_pppoe are both kernel level files, and I want to set breakpoints to find out where it is/isn't working, so kgdb seemed like the best thing to use. Given that I'm in a minority of kgdb users, what's everyone else using in cases like this? To be honest, I'm a printf debugger.
Kernel debugging setup - pccom vs com and failed mappings?
I'm trying to set up a virtualised qemu OpenBSD kernel debug environment, with a reasonable amount of success, but am running into the following problem on bootup : com1: at isa0 port 0x2f8/8 irq 3panic: com_isa_attach: mapping failed The operating system has halted Presumably because the kernel debugger is already using it (it attaches fine after the initial boot -d). I note that in a non debug kernel it's referring to pccom instead of straight com... I imagine I'm doing something wrong? My kernel config file is : include arch/i386/conf/GENERIC rmoption DDB makeoptions DEBUG=-g option KGDB option KGDB_DEVNAME=\com\,KGDBADDR=0x2f8,KGDBRATE=19200 /etc/ttys has tty01 /usr/libexec/getty std.19200 unknown off local (but it's not getting that far, is it?). Do I need to rebuild the kernel with option KGDB_DEVNAME=\pccom\,KGDBADDR=0x2fs,KGDBRATE=19200 Perhaps? Or is this a virtualisation issue? I'm using qemu 0.91 under Vista x64 with redirected serial ports (-serial tcp:binding IP address:port,server,nowait) Thanks! PK
Re: kernel debugging when booted off install cd
On Sun, 5 Feb 2006, Nick Holland wrote: Charles Sprickman wrote: Hello all, I'm still not able to get OpenBSD 3.4-3.8 loaded on my old firewall box. It either freezes or panics when probing (or creating?) rd0, which I assume is the ramdisk used in the install. It runs 3.3 fine. So rather than just asking some random questions, I'd like to know how to save a dump when booting off of the install CD. I do have a serial console available (set tty com0). If getting a dump isn't possible, I'd then like to know how to get into the kernel debugger. I figure that I can gather information that's more helpful this way. You aren't going to get nor save a dump when booting off the install CD. You really don't want a panicked kernel writing to your good data disks, do you? In this case, I don't mind. I've got another box in it's place so I'm prepared to do anything I need to do to get this running a current version of OBSD. The install kernels don't have all the bells and whistles of the production kernel, that's how they fit on floppies and such. Got it, so there's absolutely no way to dump to a disk? It looks like it tries to... I also don't have another box handy to build a custom 3.8 kernel on. And I also wonder if a non-rd kernel would panic, as the panic happens as it tries to deal with the ramdisk... Use your serial cable to capture the output of the boot process. THAT will tell us much more about your hardware. I've got a thread here: http://marc.theaimsgroup.com/?t=11366659953r=1w=2 I reposted since I just wanted to get the basics on getting a dump in OBSD. I figured once I had that, I could actually file a PR or something. A completely Wild A..ed Guess, based on the symptoms, you may have way too little RAM for the newer kernels (16M will get you running still, but 32M is a practical minimum) and floating point emulation broke after 3.3 on i386 (translation: no more 486sx or 80386 w/o 80387 support). If I were to bet, I'd say you probably have no FPU on your machine. It's old, but not that old. I've got 128MB of RAM. Processor is an AMD K6-2/500 clocked down to 300. VIA chipset. I've had memtest86+ go through about a dozen runs with no errors. 3.3 works flawlessly. Not sure where to go from here... Thanks, Charles Nick.
Re: kernel debugging when booted off install cd
On Fri, 3 Feb 2006, Rogier Krieger wrote: On 2/3/06, Charles Sprickman [EMAIL PROTECTED] wrote: It either freezes or panics when probing (or creating?) rd0, which I assume is the ramdisk used in the install. It runs 3.3 fine. Perhaps you need to look at the FAQ if you're running i386: upgrading/reinstalling OpenBSD/i386 using bsd.rd-a.out [1]. Excellent, I did not know how to boot an ELF kernel from the a.out bootloader. If that doesn't solve your problem, a dmesg would be your best bet. Information from a panic (trace/ps, obtained through the debugger you get dropped into) would also be helpful. Since you mentioned you have a serial console available, I recommend using it to file a report. OK, so I grabbed the 3.5 bsd.rd-a.out and I get the same results. Instant panic, and then a reboot. dump to 1001 dump error 19 How can I go about getting it to crash into the debugger? Thanks, Charles Upon freezes, I usually try to boot into the UKC to set the verbose option. Typically, this gave me a hint in devices to disable. As a sidenote: my own usual culprit is the ahc(4) driver. That said, this only happens with two machines, each having an nVidia nForce2 chipset. Given that you mentioned rd0 as a problem point, I doubt you are having the same underlying problem. Cheers, Rogier References: 1. OpenBSD FAQ - Upgrading/reinstalling OpenBSD/i386 using bsd.rd-a.out http://www.openbsd.org/faq/faq4.html#bsdrdaout -- If you don't know where you're going, any road will get you there.
kernel debugging when booted off install cd
Hello all, I'm still not able to get OpenBSD 3.4-3.8 loaded on my old firewall box. It either freezes or panics when probing (or creating?) rd0, which I assume is the ramdisk used in the install. It runs 3.3 fine. So rather than just asking some random questions, I'd like to know how to save a dump when booting off of the install CD. I do have a serial console available (set tty com0). If getting a dump isn't possible, I'd then like to know how to get into the kernel debugger. I figure that I can gather information that's more helpful this way. Thanks, Charles
Re: kernel debugging when booted off install cd
On 2/3/06, Charles Sprickman [EMAIL PROTECTED] wrote: It either freezes or panics when probing (or creating?) rd0, which I assume is the ramdisk used in the install. It runs 3.3 fine. Perhaps you need to look at the FAQ if you're running i386: upgrading/reinstalling OpenBSD/i386 using bsd.rd-a.out [1]. If that doesn't solve your problem, a dmesg would be your best bet. Information from a panic (trace/ps, obtained through the debugger you get dropped into) would also be helpful. Since you mentioned you have a serial console available, I recommend using it to file a report. Upon freezes, I usually try to boot into the UKC to set the verbose option. Typically, this gave me a hint in devices to disable. As a sidenote: my own usual culprit is the ahc(4) driver. That said, this only happens with two machines, each having an nVidia nForce2 chipset. Given that you mentioned rd0 as a problem point, I doubt you are having the same underlying problem. Cheers, Rogier References: 1. OpenBSD FAQ - Upgrading/reinstalling OpenBSD/i386 using bsd.rd-a.out http://www.openbsd.org/faq/faq4.html#bsdrdaout -- If you don't know where you're going, any road will get you there.
