From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14898 invoked by alias); 2 Nov 2011 20:21:23 -0000 Received: (qmail 14750 invoked by uid 22791); 2 Nov 2011 20:21:22 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Nov 2011 20:21:08 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RLhJ5-0001Gx-A1 from pedro_alves@mentor.com ; Wed, 02 Nov 2011 13:21:07 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2011 20:21:05 +0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFC: don't set the pspace on ordinary breakpoints Date: Wed, 02 Nov 2011 20:21:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.7.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Ulrich Weigand References: <201111021854.42981.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111022021.03286.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2011-11/txt/msg00053.txt.bz2 On Wednesday 02 November 2011 19:46:54, Tom Tromey wrote: > Pedro> I'm not clear how this isn't breaking multi-process without > Pedro> the linespec changes. I mean, if we no longer have a pspace > Pedro> pointer, breakpoint re-setting will no longer work correctly. > Pedro> (breakpoint_re_set -> ... -> prepare_re_set_context) > > Yeah, it probably does. > I'm not sure why this doesn't result in any regressions. Jan pointed at one in gdb.multi/. Not sure if it's related. > I won't put it in separately... it is mostly useful as a way to break > off a chunk of the huge linespec patch for readability. Yeah, thanks for that. > Pedro> I don't think that's correct. During startup, we disable user > Pedro> breakpoints, because the symbols haven't been relocated yet. > Pedro> But, we still need to insert internal breakpoints set at magic > Pedro> addresses (not through symbols), so that we know when the startup > Pedro> is done with. Ulrich? > > Ok. How would I test this? The only calls to disable_breakpoints_before_startup/enable_breakpoints_after_startup are in solib-spu.c, so you'd need testing on Cell. > Plan B would be to put the startup-disabled state on bp_location. Maybe keeping your change, but disabling only user breakpoints would be enough: @@ -1578,6 +1578,9 @@ should_be_inserted (struct bp_location *bl) if (!bl->enabled || bl->shlib_disabled || bl->duplicate) return 0; -+ if (bl->pspace->executing_startup) ++ if (user_breakpoint_p (bl->owner) && bl->pspace->executing_startup) + return 0; Though I'm not sure of the impact the bkpt_re_set change has. I'm hoping Ulrich still remembers things from when he added the startup disabled stuff. :-) On Wednesday 02 November 2011 19:46:54, Tom Tromey wrote: > Pedro> Could have been two independent patches. > Ok, noted. Thanks. IMO, the executing_startup change IMO could go in separately, as soon as it is correct, it looks quite independent. What prompted it, BTW? -- Pedro Alves