Date: Tue, 23 Apr 96 16:58:00 MDT From: Greg Lehey <lehey.pad@sni.de> To: erich@lodgenet.com (Eric L. Hernes) Cc: hackers@freebsd.org (FreeBSD hackers) Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604231458.QAA10922@nixpbe.pdb.sni.de> In-Reply-To: <199604231447.JAA21041@jake.lodgenet.com>; from "Eric L. Hernes" at Apr 23, 96 9:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Greg Lehey writes:
>>
>> I think that we should consider making these breakpoint forms more
>> generally available (e.g. via ptrace ()). Do you feel like
>> retrofitting gdb to use them?
>
> Yea, that'd be ok. I was planning to prototype it as an lkm, but
> maybe a wart on ptrace() would be just as easy.
OK, let's take this offline. I'm copying hackers for the last time.
If anybody else is interested in the discussion, please reply and I'll
copy you.
I don't see the need for an lkm (but then, I don't have much of a feel
for lkms, so I could be completely wrong). There's not too much code
involved on the kernel side, the way I see it: we need calls to:
1. Set different kinds of breakpoints (I/O read, I/O write,
Instruction fetch, Memory read, Memory write).
2. Specify address space (kernel, user, which user?) for memory
references.
3. Specify what to do when you hit a breakpoint (inform a process, or
drop into ddb).
4. Perform a minimal set of conditional checks. Setting conditional
breakpoints in gdb is very expensive, and if you have a breakpoint
in kernel space, it could become significantly more expensive.
5. Perform some kind of recovery from recursive breakpoints hits
(what happens if you hit a breakpoint while handling breakpoint
code?). I have code like that in lowbug, and it's surprisingly
simple.
Any other ideas?
On the user (gdb) side, there's more work. I looked at it a while
ago, and it was more work than I was prepared to undertake at the
time. Maybe you have better ideas about this aspect.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604231458.QAA10922>