Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Emi SUZUKI <emi-suzuki@tjsys.co.jp>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] checking the Z-packet suppport on gdbserver
Date: Fri, 14 Sep 2007 12:15:00 -0000	[thread overview]
Message-ID: <20070914121500.GA18934@caradoc.them.org> (raw)
In-Reply-To: <20070913.210822.19763360.emi-suzuki@tjsys.co.jp>

On Thu, Sep 13, 2007 at 09:08:22PM +0900, Emi SUZUKI wrote:
> GDB decides which type of watchpoints should be set when giving the
> command like "watch foo".  And hardware watchpoints can be used when
> gdbserver has the Z-packet support.  However, as the session log above
> has shown, GDB does not check the Z-packet support on gdbserver when
> deciding the type of the watchpoint but when actually setting the
> watchpoint to the target.  

This is an interesting problem.  There are a couple of parts to it.

Watchpoints are stored in a table, along with breakpoints.  The table
entries last the entire GDB session, unless they are deleted by the
user.  In that time, the user can disconnect from the remote target
and connect to a different one, or to a native process.  One of these
might support hardware watchpoints; another might not.  That's one
reason we don't check when the watchpoint is created.  But it isn't
a very good reason; you can't set hardware watchpoints before
"run" either, and no one complains about that.  We could solve
this by setting just a "watchpoint", and deciding whether it was a
"software watchpoint" or "hardware watchpoint" later on.  Or
we could just not worry about it.  Not worrying about it is
probably OK.

So on to the more relevant part.  Native targets define several
methods for dealing with watchpoints:

    int (*to_can_use_hw_breakpoint) (int, int, int);
    int (*to_remove_watchpoint) (CORE_ADDR, int, int);
    int (*to_insert_watchpoint) (CORE_ADDR, int, int);
    int (*to_stopped_by_watchpoint) (void);
    int to_have_steppable_watchpoint;
    int to_have_continuable_watchpoint;
    int (*to_stopped_data_address) (struct target_ops *, CORE_ADDR *);
    int (*to_region_ok_for_hw_watchpoint) (CORE_ADDR, int);

And, inconsistently, the gdbarch method
gdbarch_have_nonsteppable_watchpoint.

The steppable / nonsteppable / continable distinction describes what
happens after a watchpoint is hit; whether it can be single stepped
while inserted, must be removed and stepped past, or is already past.
This varies by architecture but also by target, e.g. a simulator might
implement nonsteppable watchpoints for i386 (which normally has
continuable watchpoints).

to_region_ok_for_hw_watchpoint decides whether a region is too big
or misaligned to be watched.  to_can_use_hw_breakpoint decides whether
too many hardware watchpoints have been requested.  The remote target
can't implement either of these.  Figuring out the answer to either
is a bit complicated.  Every architecture's watchpoints work a
bit differently.

Before I think about how to do it, the question is: should we bother?
Or is the any watchpoints / no watchpoints distinction good enough?
We can use qSupported to convey any information we like from the
target to GDB but once we get the data we have to figure out what
to do with it.

-- 
Daniel Jacobowitz
CodeSourcery


      parent reply	other threads:[~2007-09-14 12:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-13 12:09 Emi SUZUKI
2007-09-13 17:05 ` Jim Blandy
2007-09-14  9:40   ` [RFC] checking the Z-packet support " Emi SUZUKI
2007-09-14 12:15     ` Daniel Jacobowitz
2007-09-18 21:17     ` Jim Blandy
2007-09-18 21:28       ` Daniel Jacobowitz
2007-09-18 21:45     ` Jim Blandy
2007-09-20  9:49       ` Emi SUZUKI
2007-09-14 12:15 ` Daniel Jacobowitz [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=20070914121500.GA18934@caradoc.them.org \
    --to=drow@false.org \
    --cc=emi-suzuki@tjsys.co.jp \
    --cc=gdb-patches@sourceware.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