This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare


> Date: Tue, 31 Oct 2000 11:21:12 -0800
> From: Michael Snyder <msnyder@redhat.com>
> 
> Eli Zaretskii wrote:
> > 
> > Note that I'm working on a unified watchpoint implementation for all
> > ia32 targets, based on the code written for the DJGPP port (see
> > go32-nat.c).  This implementation will allow to watch large areas (up
> > to 16 bytes) and debug register sharing via reference counts (required
To: jtc@redback.com
CC: msalter@redhat.com, gdb-patches@sources.redhat.com
In-reply-to: <5mpukgli1x.fsf@jtc.redback.com>
Subject: Re: Remote watchpoint support.
Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
References: <200010301416.e9UEG6m18981@deneb.localdomain> <5mg0leoyg6.fsf@jtc.redback.com> <200010310906.EAA21820@indy.delorie.com> <5mpukgli1x.fsf@jtc.redback.com>
--text follows this line--
> From: jtc@redback.com (J.T. Conklin)
> Date: 31 Oct 2000 15:14:34 -0800
> 
> Did I just hear an echo?  :-)

Yes.  Isn't it true that echoes are so reassuring? ;-)

> In this case, I don't think it would be that difficult to fix.  For a 
> first cut, I'd change the macro to:
> 
>         target_stopped_data_address(&addr)
> 
> It would return 0 if GDB didn't stop because of a watchpoint, and 1
> (and set addr) if it did.

That's what I had in mind.  I thought you saw some specific problems
to make such a change.

In addition, I think it might be a good idea for breakpoint.c to use
STOPPED_BY_WATCHPOINT in the loop where it tests whether any of the
watchpoints triggered.  Using target_stopped_data_address for that, as
GDB does now, is inefficient: since the target end doesn't know
whether GDB needs the address or not, it is forced to do lots of
redundant work interrogating the debug interface.  The target end
needs to find out, for each one of the watchpoints, whether or not it
triggered, because the target_stopped_data_address API doesn't include
the information about a specific watchpoint.  If you have several
active watchpoints, this tends to an O(n^2) behavior, since GDB itself
loops over all the watchpoints.

(I'm guessing that this API peculiarity dates back to the first
platforms where watchpoints became available, where watchpoints
watched a very large area.)

Is there any reason why GDB couldn't use STOPPED_BY_WATCHPOINT inside
bpstat_stop_status?
> > for watching overlapping areas) on all ia32 platforms.
> > 
> > I am trying to make this happen for v5.1, so perhaps changes like this
> > one should be witheld and not committed, at least until we decide that
> > I'm not living up to my promises.
> 
> Is there a reason for them to be withheld?

I thought what I wrote was the reason.  But if you think it's not a
reason, or that it's not important enough, by all means go ahead and
commit the changes; that's why I said ``perhaps'' in my last sentence.

In case my wording wasn't clear: adding yet another subtly
incompatible watchpoint implementation for ia32 target might be
largely a wasted effort, since they all will have to be revisited
when/if the generalized code is finished and accepted.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]