From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116836 invoked by alias); 14 Jan 2020 15:22:14 -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 116825 invoked by uid 89); 14 Jan 2020 15:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Jan 2020 15:22:04 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E03951E4B2; Tue, 14 Jan 2020 10:22:01 -0500 (EST) Subject: Re: [PATCH 2/2][AArch64] Test handling of additional brk instruction patterns To: Luis Machado , gdb-patches@sourceware.org Cc: alan.hayward@arm.com, tankut.baris.aktemur@intel.com References: <20200113172524.7201-1-luis.machado@linaro.org> <20200113172524.7201-3-luis.machado@linaro.org> <0f4a6a0a-540b-7641-cd3e-2fef07cf3994@linaro.org> From: Simon Marchi Message-ID: <4cd3c522-393c-bff2-7546-868f4b214c56@simark.ca> Date: Tue, 14 Jan 2020 15:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <0f4a6a0a-540b-7641-cd3e-2fef07cf3994@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00375.txt.bz2 On 2020-01-14 8:30 a.m., Luis Machado wrote: > The idea behind the test is that GDB will get a SIGTRAP and be able to > step over all of the program breakpoints until the inferior exits. We > don't count how many of those breakpoints we've hit. > > If GDB gets stuck during "continue" and doesn't hit one of the > breakpoints, then we throw a fail. That failure is an indication that > something is wrong. It would just be one more consistency check. If we put 4 breakpoints in the file, but get 3 hits, there is something wrong. Your test verifies well the failure mode that you have encountered today, but by adding this check, it could catch some other types failure in the future. > If someone wants to add more breakpoint patterns to the test, the .exp > file won't need to be changed. I don't really think it's a problem to update the .exp file if you're changing the .c anyway. > Does that make sense? Or do you think it would be better to have a fixed > set of instruction the test is bound to? I would add it, but it's not necessary, I'll leave that up to you. :) Simon