From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14658 invoked by alias); 8 Sep 2007 14:44:03 -0000 Received: (qmail 14648 invoked by uid 22791); 8 Sep 2007 14:44:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Sep 2007 14:43:58 +0000 Received: (qmail 8856 invoked from network); 8 Sep 2007 14:43:56 -0000 Received: from unknown (HELO h38.net64.aknet.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Sep 2007 14:43:56 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: [4/9] associate bpstat with location Date: Sat, 08 Sep 2007 14:44:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200709080018.25052.vladimir@codesourcery.com> <200709081524.48816.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709081843.47005.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00123.txt.bz2 On Saturday 08 September 2007 16:15:35 Eli Zaretskii wrote: > > The reason why the assumption is valid is because the only way to have > > several bpstats refer to one breakpoint is when breakpoint has two > > locations, and both locations have the same address. That makes no sense -- > > there's no per-location data that can make those locations different > > in behaviour, and so having two locations with same address would > > be a bug. > > If this can happen only as a result of a bug, perhaps a gdb_assert is > in order. Yes, except there's no convenient place where assert can be placed. To assert this assumption you have to actually walk though all bpstats and check for duplication locations, and that's too much work. > > > > case bp_access_watchpoint: > > > > if (bs->old_val != NULL) > > > > { > > > > - annotate_watchpoint (bs->breakpoint_at->number); > > > > + annotate_watchpoint (b->number); > > > > > > Watchpoints also? Did you make corresponding changes in the code that > > > sets watchpoints? > > > > No. This patch is not supposed to have any change in behaviour whatsoever, > > it merely moves a data member. > > Does that mean that the display of watchpoints for "info watch" will > be now different from "info break"? *This* patch does not change input of "info break". In fact, it does not change any observable behaviour. As for future patches, the basically have two output changes: 1. Printing of multiple locations, if any 2. Printing of "(p)" Neither of those output changes are applicable to watchpoints. (1) is not applicable because watchpoints can't have multiple locations, in the same way breakpoints do. (2) is not applicable because gdb will never try to set bp_shlib_disabled state for a watchpoint, neither in the current code, nor after my patches. - Volodya