From: Bharata B Rao <bharata@in.ibm.com>
To: jmerkey@vger.timpanogas.org
Cc: kaos@melbourne.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18
Date: Thu, 24 Jan 2002 10:50:09 +0530 [thread overview]
Message-ID: <20020124105009.A26403@in.ibm.com> (raw)
In-Reply-To: <20020123140045.A17976@vger.timpanogas.org> <200201240422.g0O4MuJ26799@bharata.in.ibm.com>
In-Reply-To: <200201240422.g0O4MuJ26799@bharata.in.ibm.com>; from bharata@bharata.in.ibm.com on Thu, Jan 24, 2002 at 09:52:57AM +0530
Hi,
This is a problem that comes up when user and kernel debuggers are using
the hardware breakpoints at the sametime.
1. If more than one kernel debugger is present (for ex: DProbes and kdb),
one can ovewrite the debug register settings of the other.
2. kernel allows the gdb to override the kernel debugger's h/w bps (through
ptrace and by writing the process context dr7 during signal handling -- the
problem observed by you below).
In DProbes we have tried to address this problem by providing a centralized
global debug register allocation scheme. (See the latest DProbes code, at
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes)
In this scheme any debugger (user or kernel) wanting to use a debug register
should first get it allocated for its use. User debuggers do this transparently
using ptrace(allocations using ptrace are local to the process). Interfaces
are provided for kernel debuggers to allocate/free the debug registers on global
basis. DProbes has used this successfully and can interoperate well with gdb.
(Currently gdb is not prepared to handle failures when writing to debug
registers using ptrace, hence for now, users would get non-intuitive error
messages).
Regards,
Bharata.
In article <20020123140045.A17976@vger.timpanogas.org>, "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. Patch submitted to Keith Owens and
> Linux kernel. Jeff
--
Bharata B Rao,
IBM Linux Technology Center, IBM Software Lab, Bangalore, India.
Ph: 91-80-5044962(5262355 X-3962), Mail: bharata@in.ibm.com.
next prev parent reply other threads:[~2002-01-24 5:38 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 [this message]
2002-01-24 5:59 ` Keith Owens
2002-01-24 18:15 ` Suparna Bhattacharya
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=20020124105009.A26403@in.ibm.com \
--to=bharata@in.ibm.com \
--cc=jmerkey@vger.timpanogas.org \
--cc=kaos@melbourne.sgi.com \
--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