From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40942 invoked by alias); 12 Jan 2017 21:04:18 -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 40930 invoked by uid 89); 12 Jan 2017 21:04:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy==e5=b0=a7, H*f:sk:6199018, H*i:sk:6199018, learn?= X-HELO: mail-qt0-f196.google.com Received: from mail-qt0-f196.google.com (HELO mail-qt0-f196.google.com) (209.85.216.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jan 2017 21:04:16 +0000 Received: by mail-qt0-f196.google.com with SMTP id l7so3909980qtd.3 for ; Thu, 12 Jan 2017 13:04:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DQWBgZsQXn8S4aGdFeTTLV3G9x6svA3do5r+JFH/zI4=; b=EtJdo5PgZlJz7OsabHw0lq+C/yEEG+6MyAnTVnwNsDxK20HPLHnCGLu6M8FAYqlRsV Am5t8J5pFaxIM2LyUnX3stEsQd1/e8ZXmFhZ0dutYF7XXp9rHCXkW0ysVnBd91yWJonj luTRBQIJGpr3csWY5Qq+K+QKIqmqkK0SeJ6Wo1LU4RNgfF7qFLY3/V40cMQ2uUccDDeR msDSOYoqK0U+wUrAGYN5xPKudHdharjXjMiuqXYp2Tb4oGySGnaMDpmnn5qDWIOtTl48 yjbjP8AuaJZprA02rhySDK09dJUSzWxPVJuWicqYYW/7ZHaLb55T3AudgwbxkoAH0nWT wR4Q== X-Gm-Message-State: AIkVDXLkkZKmReFshp/tz8r2Atb/Vohed1KgwuiYsFUY5pgLaE1hISTqNbAEyCLSnjglS55AUt75L0kzjAmxrg== X-Received: by 10.237.55.196 with SMTP id j62mr12246930qtb.36.1484255054458; Thu, 12 Jan 2017 13:04:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.11 with HTTP; Thu, 12 Jan 2017 13:04:14 -0800 (PST) In-Reply-To: <61990187-ee50-997e-15de-b6b0dd74351a@redhat.com> 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> <61990187-ee50-997e-15de-b6b0dd74351a@redhat.com> From: Yao Qi Date: Thu, 12 Jan 2017 21:04:00 -0000 Message-ID: Subject: Re: [PATCH 3/8] Disassembly unit test: disassemble one instruction To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00252.txt.bz2 On Thu, Jan 12, 2017 at 5:43 PM, Pedro Alves wrote: > 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? Nothing so far. I need an assert or check that an exception should be thrown in some statement in patch #7, like EXPECT_THROW in gtest. All current unit/self tests are started by a command "maint selftests". Probably, we can't unit test event loop or command handling. > 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. > We only have one assertion SELF_CHECK, but we need more, like EXPECT_EQ, EXPECT_TRUE, etc. They can be easily added to selftest.h. I don't think of the answers of these questions either, but we should think of them at this stage, because we don't have many unit test cases yet, it is easy to change to any framework. It is difficult to change when we have thousands of unit tests on top of selftest.{c,h} framework. so, if we want to use something as a framework, be careful :) I'll try some c++ unit test frameworks in gdb, and see what I can get. --=20 Yao (=E9=BD=90=E5=B0=A7)