From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: "Jeff V. Merkey" <jmerkey@timpanogas.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18
Date: Thu, 24 Jan 2002 13:15:19 -0500 [thread overview]
Message-ID: <3C504F37.9FF10EF0@in.ibm.com> (raw)
In-Reply-To: <20020123140045.A17976@vger.timpanogas.org> <2504.1011851961@kao2.melbourne.sgi.com>
Keith Owens wrote:
>
> On Wed, 23 Jan 2002 14:00:45 -0700,
> "Jeff V. Merkey" <jmerkey@vger.timpanogas.org> wrote:
> >Please find a patch that corrects the problem with hardware
> >breakpoints not working with kdb. I have noticed that gdb uses
> >inserted int3 (0xCC) breakpoints (as does kdb) for soft breakpoint
> >support, so this fix may not affect these programs. It is not
> >clear why every signal handled is writing a 0 t the DR7 register.
>
> Not a 0, it is %0, gcc asm parameter 0. There used to be a bug in
> ptrace handling where db7 would get cleared in taps.c and would not get
> reinstated until one timeslice after the initial trap. Fixed by James
> Cownie in June 2000 by reinstating db7 before passing the signal to
> user space.
>
> The conflict with kdb is inherent in the lack of a kernel interface for
> assigning debug registers.
As Bharata mentioned this sort of a thing is exactly what we use today
in dprobes. Guess we could separate out that piece as a patch so you can
take a look. We had posted one long back on this list, but have now
cleaned
up and reorganized it a bit. In fact we've used this for a while for
preparing
consolidated patches containing both dprobes and kdb, in a way that also
interoperates with gdb (we don't want our watchpoint settings to get
overwritten
on a context switch for example).
>gdb/ptrace always uses i386 db4-7 no matter
> what kdb is doing. The kernel always uses db7, even if no tracing is
> being done. If you want to use gdb/ptrace then restrict your kdb usage
> to db0-3, without gdb/ptrace kdb can use db0-6.
>
> It would be nice to have a proper debug register function to
> automatically detect conflicts and tell one of the debuggers to go
> away. However Linus "I don't want kernel debuggers" Torvalds does not
> care about this problem and I don't want the footprint of kdb to be any
> bigger than it has to be. So kdb relies on the user to know which
> debug registers then can use.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2002-01-24 12:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-23 21:00 [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18 Jeff V. Merkey
[not found] ` <200201240422.g0O4MuJ26799@bharata.in.ibm.com>
2002-01-24 5:20 ` Bharata B Rao
2002-01-24 5:59 ` Keith Owens
2002-01-24 18:15 ` Suparna Bhattacharya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C504F37.9FF10EF0@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=jmerkey@timpanogas.org \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox