This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] checking the Z-packet suppport on gdbserver
- From: Daniel Jacobowitz <drow at false dot org>
- To: Emi SUZUKI <emi-suzuki at tjsys dot co dot jp>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 14 Sep 2007 08:15:00 -0400
- Subject: Re: [RFC] checking the Z-packet suppport on gdbserver
- References: <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