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
prev parent 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