Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Peter Jansen <peter@klaxoniqa.com>
Cc: gdb@sources.redhat.com
Subject: Re: Hardware Breakpoints
Date: Tue, 19 Mar 2002 06:59:00 -0000	[thread overview]
Message-ID: <3C97522E.8090407@cygnus.com> (raw)
In-Reply-To: <3C954349.B1B5B446@klaxoniqa.com>

> Hi,
> 
> 
>> > I'm trying to use hardware breakpoints in gdb (in the new
>> > gdbarchitecture stuff) and cannot figure out how it all works. Are their
>> > any gdbarch things for hardware breakpoints and watchpoints?
>> >
>> > Are there any targets that use hardware breakpoints and watchpoints in
>> > the new gdbarch stuff?
> 
>> 
>> No.  But there is a reason.
>> 
>> The existing h/w breakpoint macros should be moved to the target vector
>> and not the architecture vector.  This is because the target, and not
>> the architecture, determines the presence of a breakpoint mechanism.
>> 
>> Unfortunatly, so far, no one has made this change, sigh!
>> 
>> Interested?
> 
> 
> hmm, I have an embedded target and I connect to it via a JTAG box, so
> the target has hardware breakpoints, I assume we need to define them in
> avr-tdep.c and put the hooks in the correct place to tie it together? 
> 
> What I see at the moment is the breakpoint.c stuff has no connection to
> the avr-tdep.c file and I cannot see how to define something in avr-tdep
> and let breakpoint.c use it.
> 
> Do you have some ideas about how this is supposed to work?

At this point, things get confusing.  I'll answer the ``supposed to 
work'' question (how it works, is people define those macros).

Two possabilities:

a. You're connecting to a remote target that supports the hardware 
breakpoint/watchpoint mechanism.

GDB just sends h/w breakpoint requests through to the target.  For this 
to work you need to hardwire (:-() up the hw_* functions in remote.c.

(This shouldn't be hardwired.  Instead it should be part of the target 
vector.)

b. Your target doesn't have a remote h/w breakpoint mechanism but does 
have access to the h/w breakpoint registers.

Implements h/w breakpoints locally by directly manipulating the relevant 
registers (i386 does this).  For this to work you hardwire (:-() code in 
your *-tdep.c file to those macros.

(This shouldn't be hardwired either.  Instead, the target vector, 
realising that it can't implement h/w breakpoints directly should ask 
the architecture vector for assistance.)

Andrew




      reply	other threads:[~2002-03-19 14:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-17 16:58 Peter Jansen
2002-03-17 17:09 ` Andrew Cagney
2002-03-17 17:30   ` Peter Jansen
2002-03-19  6:59     ` Andrew Cagney [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=3C97522E.8090407@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=peter@klaxoniqa.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