Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Ben Johnson <ben@blarg.net>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: how are debug registers supposed to work?
Date: Thu, 04 Sep 2003 00:17:00 -0000	[thread overview]
Message-ID: <20030903171748.A3111@blarg.net> (raw)
In-Reply-To: <3F567176.1000100@redhat.com>; from ac131313@redhat.com on Wed, Sep 03, 2003 at 06:55:50PM -0400

Thanks for the response.

Everything on this box is carefully (as possible) controlled.  I have
removed all reference to the debug registers throughout the kernel.  (I
don't know if they can be accessed directly from user space, but I would
guess not.)

I've turned on the 'GD' bit in %db7.  That causes a debug exception
(int1) to be thrown when any of the debug registers are accessed or
written to.  I believe they're not be fooled with because, unless I
purposefully read or write to the debug regs now, I never get a debug
exception.

I've tried setting both code and data break/watchpoints, and none of
them seem to work at all.  I know the interrupt handler is setup
correctly because I do get the interrupt when the GD bit is set and I
try to read %db7.  I've found no other way to make these register do
anything though.  I've given up.  I think they just don't work.

but, how could they not work?  There *must* be something I'm not
understanding.

I gave up leaving anything to chance and started putting code like this
in the (2.0 Kernel) schedule() function:

if( first_time ) {
    static unsigned long testvar = 0;
    unsigned long db7;

    first_time = 0;

    /* maybe flush and disable the cache here.  doesn't matter. */

    asm ("movl %0, %%db0\n"
         "  movl %1, %%db7\n"
         : /* no output */
         :"a"(&testvar),    /* put &testvar in db0 */
         "b"(0x000f2202)    /* watch 4 bytes for reads or writes
                             * at &testvar globally and set GD */
        );

    testvar = 0xffffffff; /* change all the bits */

    /* should get a debug exception here */

    printk(KERN_DEBUG "%s: any luck?\n", __FUNCTION__);

    asm ("movl %%db7, %0\n"  /* this movl triggers a debug exception. */
         :"=a"(db7)
        );
}


What am I not getting?  I think there must be another bit I need to set
or the data I'm using is not properly aligned (in some way I don't
understand) or maybe this register has to be enabled by the bios?  who
knows.

- Ben




On Wed, Sep 03, 2003 at 06:55:50PM -0400, Andrew Cagney wrote:
> 
> Just a thought, you're not fighting a user space process playing with 
> those registers?
> 
> The other is to look at GDB using hardware debug registers on a user 
> process.
> 
> Andrew
> 
> 


  reply	other threads:[~2003-09-04  0:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-29  0:41 Ben Johnson
2003-09-03 22:55 ` Andrew Cagney
2003-09-04  0:17   ` Ben Johnson [this message]
2003-09-17  0:30 ` Ben Johnson

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=20030903171748.A3111@blarg.net \
    --to=ben@blarg.net \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    /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