Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Eli Zaretskii <eliz@gnu.org>]

> From: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
> Date: Wed, 5 May 2004 00:08:29 +0200 (CEST)
> 
> We don't define target_stopped_data_address, and *cannot* do so
> because the hardware doesn't provide this information.
> 
> We do know whether a SIGTRAP was due to a (any) watchpoint or not,
> however, and define STOPPED_BY_WATCHPOINT to indicate this.

So the s390(x) has a means of telling that some watchpoint fired, but
there's no way to know which one, is that true?

> (Since the hardware supports only write watchpoints, not read
> or access watchpoints, this should -and used to- be enough for
> gdb to find out what happened by manually checking watchpoint
> values.)

If the hardware supports only write watchpoints, and since you don't
know what address triggered a watchpoint, this would seem to imply
that there's no way of getting awatch and rwatch commands to give
useful results, is that right?  So what does GDB on the s390 do when
the user tries to invoke awatch or rwatch?

> The patch below uses STOPPED_BY_WATCHPOINT instead of 
> target_stopped_data_address in bpstat_stop_status;
> this get s390(x) watchpoints back functional.

Thanks, I think we should make this change.

Mark, can the SVR4-derived systems be fixed by this patch?  If so, we
at least have the same functionality we had before Orjan's patch,
without reintroducing the problem he fixed.

> Alternatively, we could also make the target_stopped_data_address
> check only for read and access watch points, *not* for write
> watchpoints ...

GDB should use the result of target_stopped_data_address to find out
which watchpoints are candidates for being a possible reason for
causing SIGTRAP.  GDB doesn't do so right now, but that's because the
hardware watchpoints handling is an incremental modification of the
original code that handled only software watchpoints.

So right now, target_stopped_data_address is almost an alias for
STOPPED_BY_WATCHPOINT, but it is IMHO wrong to continue this illusion
into the future.  Therefore, I like your patch better than the
alternative which would modify target_stopped_data_address.