From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18843 invoked by alias); 19 Sep 2007 18:27:40 -0000 Received: (qmail 18828 invoked by uid 22791); 19 Sep 2007 18:27:39 -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; Wed, 19 Sep 2007 18:27:35 +0000 Received: (qmail 14815 invoked from network); 19 Sep 2007 18:27:33 -0000 Received: from unknown (HELO h38.net64.aknet.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Sep 2007 18:27:33 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: [4/9] associate bpstat with location Date: Wed, 19 Sep 2007 18:27:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200709080018.25052.vladimir@codesourcery.com> <200709081843.47005.vladimir@codesourcery.com> In-Reply-To: <200709081843.47005.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709192227.27428.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/msg00255.txt.bz2 On Saturday 08 September 2007 18:43:46 Vladimir Prus wrote: > 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. Eli, are you happy with the explanations above? - Volodya