Re: i386 Hardware watchpoints using kgdb-2-2.6.14.tar.gz

Sorry to Tom for the duplicate, I wound up sending this to him
instead of the list originally:

Hi again, a couple of things...

First, I did pick up the kprobes patch Tom subsequently posted. It
applied with a couple of trivial conflicts to the kgdb-patched
2.6.14.3 kernel that I'm using.  I did not include the second patch
which adds kwatch-points--it's a neat feature but not directly
related to kgdb.

Do you want a copy of the resulting debug register allocation
patch?

Second, I'm almost done with the hardware break/watchpoint work.
It only remains to make it use the debug register allocation mechanism
rather than do its own.  Along the way I was left wondering why
kernel/kgdb.c has that funky dual mechanism for hooking in
hardware breakpoints.  You have the weakly declared kgdb_set_hw_break
and friends, which are used only by i386/x86_64/ia64, and you also
have pointers to {set,remove}_hw_breakpoint available through kgdb_ops,
which is currently only used by ia64.

Is one of those mechanisms deprecated? I chose for the moment to
use the call through kgdb_ops.

OK, I lied, there is actually a third issue.  You can't, in
kernel/kgdb.c, just pass the ASCII type code from the Z packet
to kgdb_ops->set_hw_breakpoint() without having the compiler
complain.  The procedure wants a value there that's an
enum kgdb_bptype.  So, I added a static translation array to
pass such a value.  The i386 callee then has to use a similar
array to change the enum to something specific to the field
in i386's dr7.

Anyone have a problem with that?  This breaks the current ia64
routines, of course.  I can supply the corresponding fix but
have no way to test it myself.

  --Dennis


Tom Rini wrote:
> On Fri, Dec 16, 2005 at 10:39:42AM +0530, Amit Kale wrote:
>
>
> > Dennis,
> >
> > That would be splendid. When a watchpoint is required, no other feature can do 
> > the job!
>
>
> Note that to do this correctly, you have to be aware of other potential
> users.  Prasanna Panchamukhi of the kprobes project forwarded me some
> code that would do this and I'll send that along to the list
> momentarily.
>
>
> > -Amit
> >
> > On Friday 16 Dec 2005 12:41 am, Dennis W. Tokarski wrote:
> >
> > > Hi,
> > >
> > > Amit Kale wrote:
> > >
> > > > On Thursday 15 Dec 2005 8:40 pm, Tom Rini wrote:
> > > >
> > > > > On Fri, Dec 09, 2005 at 12:42:39PM +0530, Amit Kale wrote:
> > > > >
> > > > > > On Thursday 08 Dec 2005 11:13 pm, Dennis W. Tokarski wrote:
> > >
> > > [snip]
> > >
> > >
> > > > > I'm fairly certain we don't support watchpoints, and I don't
> > > > > _think_ we ever did on i386 (we may have on ia64 at some point).  If the
> > > > > packet isn't [zZ][01] we relpy back to GDB that it's unsupported.
> > >
> > > True. But the first problem was gdb wasn't sending out Z packets anyway.
> > > I have a temporary hack to fix that, but gkdb still doesn't set an
> > > execution break point with Z1. It seems instead to set a data access
> > > watchpoint.  As I mentioned before, I was able to manually send Z
> > > packets using the maintenance command and got the same result.
> > >
> > > So, kgdb isn't setting the watchpoint up even when it gets the
> > > right packets.  btw, I'm working exclusively on i386, so that's
> > > all I can speak to.
> > >
> > > Anyway, what I propose to do is look back at an earlier kgdb
> > > which did to all those things correctly--I've got a 2.4.18
> > > kernel here set up that way--and bring the code forward into
> > > the current kgdb for i386.  As part of that I'll handle the
> > > additional Z packets.
> > >
> > > And there's still the problem with gdb itself, and why they
> > > broke Z packets, but I'll take that up on the gdb list.
> > >
> > >
> > > > We didn't have support for official version of gdb watchpoints, though
> > > > one could send "y" packets using "maintenance packet" commands. It
> > > > worked. That was a couple of years ago, I believe. I can't recall when we
> > > > removed support for y packets. Present code doesn't support it for sure.
> > > >
> > > > -Amit
> > >
> > > I was certainly working with the macros back in the 2.4.18 days,
> > > but this is the first time I've used kdgb in 2.6.  A lot has
> > > changed, not just with kgdb.
> > >
> > >   --Dennis
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > > files for problems?  Stop!  Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > > _______________________________________________
> > > Kgdb-bugreport mailing list
> > > Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Kgdb-bugreport mailing list
> > Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click