From owner-freebsd-hackers  Tue Apr 23 08:03:49 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA08852
          for hackers-outgoing; Tue, 23 Apr 1996 08:03:49 -0700 (PDT)
Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA08321
          for <hackers@freebsd.org>; Tue, 23 Apr 1996 07:58:30 -0700 (PDT)
Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id QAA10922 for hackers@freebsd.org; Tue, 23 Apr 1996 16:58:02 +0200
Message-Id: <199604231458.QAA10922@nixpbe.pdb.sni.de>
Subject: Re: request for a new "feature" as regards DDB
To: erich@lodgenet.com (Eric L. Hernes)
Date: Tue, 23 Apr 96 16:58:00 MDT
From: Greg Lehey <lehey.pad@sni.de>
Cc: hackers@freebsd.org (FreeBSD hackers)
In-Reply-To: <199604231447.JAA21041@jake.lodgenet.com>; from "Eric L. Hernes" at Apr 23, 96 9:47 am
X-Mailer: xmail 2.4 (based on ELM 2.2 PL16)
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


> 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