From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21110 invoked by alias); 10 Oct 2017 18:33:03 -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 21101 invoked by uid 89); 10 Oct 2017 18:33:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1811, forth, Nice, HContent-Transfer-Encoding:8bit 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, 10 Oct 2017 18:33:00 +0000 Received: by simark.ca (Postfix, from userid 112) id 50A411E53D; Tue, 10 Oct 2017 14:32:58 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id C32B01E523; Tue, 10 Oct 2017 14:32:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 10 Oct 2017 18:33:00 -0000 From: Simon Marchi To: Peeter Joot Cc: gdb-patches@sourceware.org Subject: Re: review request: implementing DW_AT_endianity In-Reply-To: References: <0f87cf42-781d-4d70-a389-f4688cde109d@simark.ca> ,<534b7f80-c778-d5ca-3cee-1ccbab7bf257@simark.ca> Message-ID: X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.0 X-SW-Source: 2017-10/txt/msg00252.txt.bz2 On 2017-10-10 14:16, Peeter Joot wrote: >> I suggest naming this function type_byte_order. Functions named >> "gdbarch_*" are usually > >> those part of the gdbarch interface (defined in gdbarch.sh/.h/.c). > > > done. > >> Nice. Assginment of fields by GDB would be a good thing to check in >> the test. > > done. > >> Ah indeed. Do you report the gcc bugs you find to them? > > I will verify first on the dev version of gcc8 that this is still an > issue before submitting a report. > >> testsuite. > > It is normal to see the number of tests vary when running the test > suite (make check -j8)? My before and after runs had an unexpected > difference in the numbers of tests: > > === gdb Summary === > > > > -# of expected passes 40087 > > -# of unexpected failures 96 > > +# of expected passes 40082 > > +# of unexpected failures 98 > > # of unexpected successes 1 > > # of expected failures 67 > > # of unknown successes 3 > > > My test added 4 additional expected passes (and I verified that my new > tests ran in gdb/testsuite/gdb.log), so the number of expected > successes should have grown by 4, not decreased by 5? Some of the > failures differences look like buggy tests (outputting pids and so > forth). > > I clearly didn't regress anything significant, but didn't expect the > baseline to vary run to run. > > Peeter Yeah, it's possible for the total number of test to vary when tests start failing. For example, you can have: if [something] { fail "couldn't fetch variable" return } gdb_test "..." gdb_test "..." If it succeeds, you'll have 2 pass, 0 fail. If [something] fails, you'll have 0 pass, 1 fail. If your case you have 2 more unexpected failures, I would look into these, see if they are related. Which tests are they from? Simon