kdb(1): Introduce kdb(1)

[minsoochoo0122_proton.me]

Summary

kdb(1) is a shell script wrapper around lldb(1), providing interface similar to kgdb(1). It is translated from kgdb-main.c file in kgdb(1) port.

There are three options removed:

-w: How does -w in kgdb differ from lldb memory write?
-a: lldb doesn't support this (emacs specific)
-q: lldb doesn't show copyright banner

kdb(1) passes --source-quietly to lldb by default. This can be turned off with verbosity level 3.
Not implemented yet, but printing msgbuf is disabled through batch mode, not by -q.

Test Plan

Tested for most cases, but I don't have any device for -r testing, which means it should be done by someone else.

[emaste]

-w opens /dev/mem RW; without -w attempts to write will fail.

[minsoochoo0122_proton.me]

In D54895#1254974, @emaste wrote:

-w opens /dev/mem RW; without -w attempts to write will fail.

From lldb:

kvm_t *kvm =
        kvm_open2(executable->GetFileSpec().GetPath().c_str(),
                  crash_file->GetPath().c_str(), O_RDONLY, nullptr, nullptr);

Would it be fine to open it with O_RDWR? What is the advantage we get from readonly mode?

[emaste]

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

I don't think lldb has a way that we could do something like this on the command line, but it ought to. It would be nice to support something like ssh's -o (although -o specifically is already taken) so that we could e.g. -o kernel-rw=yes or -o aslr=no.

[minsoochoo0122_proton.me]

In D54895#1254999, @emaste wrote:

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

I don't think lldb has a way that we could do something like this on the command line, but it ought to. It would be nice to support something like ssh's -o (although -o specifically is already taken) so that we could e.g. -o kernel-rw=yes or -o aslr=no.

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

[emaste]

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

We can also implement it in the copy in our tree and replace it with what ends up upstream. Most important is just to have agreement with upstream on the command-line interface so that we don't introduce a breaking change later on.

[minsoochoo0122_proton.me]

In D54895#1255107, @emaste wrote:

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

We can also implement it in the copy in our tree and replace it with what ends up upstream. Most important is just to have agreement with upstream on the command-line interface so that we don't introduce a breaking change later on.

Okay, I'll backport to our tree after Dimitry finishes his llvm import. But since it's unclear how upstream would respond as well as the progress on importing llvm 21, I think it would be better to review this now and bring -w change later.

[emaste]

In D54895#1255113, @minsoochoo0122_proton.me wrote:

Okay, I'll backport to our tree after Dimitry finishes his llvm import. But since it's unclear how upstream would respond as well as the progress on importing llvm 21, I think it would be better to review this now and bring -w change later.

Yes we certainly can (and should) make incremental improvements.

I hope that @jhb can offer some commentary on the history of kgdb though.

[ziaee]

usr.sbin/kdb/kdb.1

31

This doesn't need to be quoted.

48

Don't use macros here.

53

New sentences start on new lines.

114

[minsoochoo0122_proton.me]

fix man page

[jhb]

You definitely don't want '-w' by default as it is quite dangerous, but it can be useful on a live system to be able to modify variables in the kernel, and it does mean passing O_RDWR to kvm_open().

I have come close to replacing kgdb with a shell script as well since kernel support is part of the regular gdb in modern versions of the port/package. Dealing with -r and the logic to find a matching kernel are the more complicated bits and you've done the second part here. FWIW, I haven't used -r in a long, long time. With VMs and QEMU instances I prefer to use a debugger in the hypervisor itself vs options GDB from the running kernel. I also tend to just use target remote ..blah blah.. in gdb directly as well instead of -r anyway, so I don't think it is critical.