From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43269 invoked by alias); 12 Jan 2017 17:43:26 -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 43230 invoked by uid 89); 12 Jan 2017 17:43:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=201506, runner, 2015-06, sk:dgextr X-Spam-User: qpsmtpd, 2 recipients 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; Thu, 12 Jan 2017 17:43:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 3F64C13A5E; Thu, 12 Jan 2017 17:43:15 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0CHhDTp001923; Thu, 12 Jan 2017 12:43:14 -0500 Subject: Re: [PATCH 3/8] Disassembly unit test: disassemble one instruction To: Yao Qi References: <1484051178-16013-1-git-send-email-yao.qi@linaro.org> <1484051178-16013-4-git-send-email-yao.qi@linaro.org> <7d906c42-2c58-bc64-376d-0e43d5176ec3@redhat.com> <20170112170307.GG31406@E107787-LIN> Cc: binutils@sourceware.org, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <61990187-ee50-997e-15de-b6b0dd74351a@redhat.com> Date: Thu, 12 Jan 2017 17:43: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: <20170112170307.GG31406@E107787-LIN> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00249.txt.bz2 On 01/12/2017 05:03 PM, Yao Qi wrote: > On 17-01-12 13:06:26, Pedro Alves wrote: >> I'd much prefer if the core of the unit testing framework doesn't learn >> about different random subsystems. Consider what we'd do if we >> wanted to reuse selftest.c in gdbserver. I think we will at some point. > > Can we consider using some general c++ unit test frameworks rather than > selftest.c? I don't see any issues if we can merge the unit test > results into dejagnu test result gdb.sum. We can consider anything, of course. But I don't know whether that's give us any significant advantage. I never evaluated any myself. Do we miss something important with the current framework? Would it be used as an as external dependency (required? optional?), or would we import it into the codebase? How would it affect the way we write tests? And the way we write the code that ends up tested? Would it force something on the codebase that would be undesirable? Etc., etc. > It should be straightforward to convert some c++ unit test result > to the dejagnu style, and use dg-extract-results.sh to merge them > into a single gdb.sum. > > David proposed using gtest in gcc unit test, and the major objection > /concern is we may have two different format of test results. > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html but the > concern can be addressed as I stated above. > >> >> How about we move all this gdbarch stuff elsewhere, like >> gdb/arch-utils.c or a new gdb/arch-selftests.c? >> > > OK, I'd like to name it as gdb/selftests-arch.c, because > arch-selftests.c looks like "a unit test case of arch". However, > I want this file serves as "a runner to run one test case for every > gdbarch". Makes sense. Thanks, Pedro Alves