From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6745 invoked by alias); 25 Jan 2017 17:44:24 -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 6729 invoked by uid 89); 25 Jan 2017 17:44:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=multitude, H*f:sk:f0007a1, H*MI:sk:f0007a1, H*i:sk:f0007a1 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 17:44:22 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22A42C04B943; Wed, 25 Jan 2017 17:44:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PHiFGh007855; Wed, 25 Jan 2017 12:44:20 -0500 Subject: Re: [PATCH/RFC] Refactor gdb.reverse/insn-reverse.c To: Luis Machado , Yao Qi References: <1484593854-1791-1-git-send-email-lgustavo@codesourcery.com> <20170125161011.GW28060@E107787-LIN> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 25 Jan 2017 17:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00544.txt.bz2 On 01/25/2017 04:50 PM, Luis Machado wrote: > On 01/25/2017 10:10 AM, Yao Qi wrote: >> On 17-01-16 13:10:54, Luis Machado wrote: >>> I've broken up the main file into other files with arch-specific bits >>> (insn-support-.c). The main file will hold the generic pieces >>> that will >>> take care of calling the tests. >>> >> >> It is reasonable to me. Can we name arch-specific files as >> insn-reverse-.c? >> > > Thanks for the review. > > Would you reconsider this? I named it insn-support-.c because we > already know this is a reverse debugging test (from gdb.reverse) and we > are really testing instruction support. I'm fine either way though, and > just wanted to add a little bit more context in the name. My 2c nit. "support" doesn't sound ideal to me. By that logic, every test in the testsuite is testing gdb's support of some feature, so "support" is redundant? When I see a file named "support", I think it's some base/foundation (==support) framework. Is that the case here? I had understood that the "base" is in insn-reverse.c instead? Or are the insn-support-.c files meant to be shared between multiple test cases, thus they'll be providing "support" for a multitude of random tests? insn-reverse-.c at least gave a hint that the files are all related to insn-reverse.c. Also, if "reverse" is redundant in "insn-reverse-.c", then it is also redundant in "insn-reverse.c" too, so you should be arguing for renaming "insn-reverse.c|exp" -> "insn-support.c|exp" too, which would preserve the similarity of the names between the driver file + the arch files. Thanks, Pedro Alves