From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80163 invoked by alias); 18 May 2017 09:54:11 -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 80127 invoked by uid 89); 18 May 2017 09:54:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-pg0-f41.google.com Received: from mail-pg0-f41.google.com (HELO mail-pg0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 May 2017 09:54:08 +0000 Received: by mail-pg0-f41.google.com with SMTP id x64so20418233pgd.3 for ; Thu, 18 May 2017 02:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=RmaXJ1v/ufM3H9fx4nxDzeYryCqan7NkT5YEkCKtrko=; b=m+jCQpcs8YERMdbp3bOx1QPpete5oBWtEab6p2L4kCBiPXjiUQZZyxjhn1Zti3YZ7e h0rCSIhNMOK6wyBI7ihr0vtGEqNC7yFIvhm3ejp/lwgojHzc5jyM6q5iY/sFc2OCGaga 2ihlbWvwPnkhRAmLB7IYTuYJfHym9uZjKQke1F+tALFho9qh82eWDKJYdzEsXyOi69kV JGgh8lD6e7ZQfUzV9grxmMrjzbQ/6NXxfX4pftpHEcf2P/PKQpwtoIOw3FA0+s+arvJa 8TawGf6T9D8fND4i2AxOgzy+dDsqinhgS3+6H/eUqi2UCcsTYTjATQuvHSTyUPMghjcq bQgQ== X-Gm-Message-State: AODbwcB6HTik/HYxDqXaHJY4dzE6E/945e2c2/c0WWMMJ0lQoopSVdb3 JD/RYSkvcGMYPOYC X-Received: by 10.99.130.73 with SMTP id w70mr3540102pgd.119.1495101250360; Thu, 18 May 2017 02:54:10 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id p10sm8640998pgf.63.2017.05.18.02.54.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 18 May 2017 02:54:09 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC 2/7] Add unit test to builtin tdesc generated by xml References: <1494518105-15412-1-git-send-email-yao.qi@linaro.org> <1494518105-15412-3-git-send-email-yao.qi@linaro.org> <692db623-3694-b809-4075-293c0d70cf5e@redhat.com> Date: Thu, 18 May 2017 09:54:00 -0000 In-Reply-To: <692db623-3694-b809-4075-293c0d70cf5e@redhat.com> (Pedro Alves's message of "Wed, 17 May 2017 16:41:27 +0100") Message-ID: <86bmqq8p8h.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00411.txt.bz2 Pedro Alves writes: >> +{ >> + std::string feature_dir (ldirname (__FILE__)); >> + struct stat st; > > Ugh. Obviously this can't work if gdb is installed / copied elsewhere, > remote host testing, etc. > I thought about this, but I can't figure out one better than __FILE__. What I want to do is to find srcdir, and open these xml files during unit tests. Since it is a unit test, I expect gdb is executed in either builddir/gdb or builddir/gdb/testsuite. I don't see a case that people build gdb in one place, and run unit/self tests somewhere else. >> + >> + /* Look for the features directory. If the directory of __FILE__ can= 't >> + be found, __FILE__ is a file name with relative path. Guess that >> + GDB is executed in testsuite directory like ../gdb, because I don't >> + expect that GDB is invoked somewhere else and run self tests. */ >> + if (stat (feature_dir.data (), &st) < 0) >> + { >> + feature_dir.insert (0, SLASH_STRING); >> + feature_dir.insert (0, ".."); >> + >> + /* If still can't find the path, something is wrong. */ >> + SELF_CHECK (stat (feature_dir.data (), &st) =3D=3D 0); > > Do we want to flag this as an error / unit test failure? > Maybe it should be a warning instead? > We can skip this test if it can't find "features" directory in source, but something wrong can be easily ignored if we do so. >> --- a/gdb/target-descriptions.h >> +++ b/gdb/target-descriptions.h >> @@ -162,6 +162,12 @@ enum gdb_osabi tdesc_osabi (const struct target_des= c *); >> int tdesc_compatible_p (const struct target_desc *, >> const struct bfd_arch_info *); >>=20=20 >> +/* Compare target descriptions TDESC1 and TDESC2, return true if they >> + are identical. */ >> + >> +bool tdesc_equals (const struct target_desc *tdesc1, >> + const struct target_desc *tdesc2); > > Any reason this and the other equals functions aren't operator=3D=3D > implementations? tdesc_reg, tdesc_type, tdesc_feature and target_desc should be class-fied first, including adding proper ctor, dtor, etc. I thought it must be a lot of work, so I don't do that. I can do that if it doesn't take me much time. > It's not obvious since the comments say "identical", which would maybe > suggest that > there may be some property that is not being compared and thus this is not > strict value equality, but then function name says "equals". I think "identical" implies "strict value equality". The information I want to deliver is that this function compares all properties, return true if they are exactly the same. Is it this better, /* Return true if target description TDESC1 and TDESC2 are equal. */ --=20 Yao (=E9=BD=90=E5=B0=A7)