From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22545 invoked by alias); 5 May 2004 05:08:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22417 invoked from network); 5 May 2004 05:07:59 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 5 May 2004 05:07:59 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1BLEba-0008Ou-9T; Wed, 05 May 2004 01:06:02 -0400 Date: Wed, 05 May 2004 05:08:00 -0000 Message-Id: From: Eli Zaretskii To: Ulrich Weigand CC: orjan.friberg@axis.com, kettenis@chello.nl, gdb-patches@sources.redhat.com, drow@false.org In-reply-to: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> (message from Ulrich Weigand on Wed, 5 May 2004 00:08:29 +0200 (CEST)) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Reply-to: Eli Zaretskii References: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> X-SW-Source: 2004-05/txt/msg00131.txt.bz2 > From: Ulrich Weigand > 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.