From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11830 invoked by alias); 28 Mar 2014 17:32:55 -0000 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 Received: (qmail 11820 invoked by uid 89); 28 Mar 2014 17:32:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 28 Mar 2014 17:32:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2EAE411653F; Fri, 28 Mar 2014 13:32:52 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dGy9N1iGZSKn; Fri, 28 Mar 2014 13:32:52 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DFC0B116536; Fri, 28 Mar 2014 13:32:51 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6162CE07F2; Fri, 28 Mar 2014 10:32:51 -0700 (PDT) Date: Fri, 28 Mar 2014 17:32:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Anton Blanchard , gdb-patches@sourceware.org, emachado@linux.vnet.ibm.com, luis_gustavo@mentor.com, ulrich.weigand@de.ibm.com Subject: Re: [PATCH 2/4] Support up to 3 conditional branches in an atomic sequence Message-ID: <20140328173251.GJ4030@adacore.com> References: <1395978111-30706-1-git-send-email-anton@samba.org> <1395978111-30706-2-git-send-email-anton@samba.org> <20140328131230.GE4030@adacore.com> <5335AD94.4030701@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5335AD94.4030701@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00666.txt.bz2 > > IIUC, it looks like MAX_SINGLE_STEP_BREAKPOINTS is actually not > > the max, but MAX - 1. I was a little confused by that. Why not > > change MAX to 3, and then adjust the array definition and code > > accordingly? I think things will be slightly simpler to understand. > > IMO that would be more confusing. I read MAX_SINGLE_STEP_BREAKPOINTS > as meaning the "maximum number of of single-step breakpoints we > can create simultaneously". I think you're reading it as > "the highest index possible into the single-step breakpoints > array" ? Here is how I read the patch: MAX_SINGLE_STEP_BREAKPOINTS is the size of the array, and we rely on the last element always being NULL to determine the number of "live" elements we actually have. Hence, to me, the maximum number of SS breakpoints we can handle in practice is not MAX_SINGLE_STEP_BREAKPOINTS but 1 less. For instance, I think the patch is trying to increase the number of SS breakpoints to 3, and yet defines MAX_SINGLE_STEP_BREAKPOINTS to 4. Perhaps it's time to just use a vec? That way, we don't have a limit at all anymore... -- Joel