From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26045 invoked by alias); 12 Aug 2019 21: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 25927 invoked by uid 89); 12 Aug 2019 21:44:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Everyone, spending 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; Mon, 12 Aug 2019 21:44:18 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3527D89AC0; Mon, 12 Aug 2019 21:44:17 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id EA0D980932; Mon, 12 Aug 2019 21:44:16 +0000 (UTC) From: Sergio Durigan Junior To: Tom de Vries Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) References: <20190714175240.GA23822@adacore.com> Date: Mon, 12 Aug 2019 21:44:00 -0000 In-Reply-To: (Tom de Vries's message of "Tue, 16 Jul 2019 15:02:38 +0200") Message-ID: <877e7i3vpr.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00255.txt.bz2 On Tuesday, July 16 2019, Tom de Vries wrote: > On 14-07-19 19:52, Joel Brobecker wrote: >> Hi Everyone, >> >> It's been a couple months since we released 8.3 already. Our typical >> schedule would be to try to create the corrective release ("re-spin") >> in about a month from now. Given that... >> - So far, there is only been one fix pushed to the branch since >> the release; and >> - that a month from now is mid-Aug, which is holiday time for many; >> ... I purpose we don't do anything until end of Aug... >> >> Depending on when we'd like to have GDB 9 come out, we might even >> want to skip 8.3.1 entirely? Personally, I don't mind spending the couple >> of hours it takes to create a new release, even if it's for a couple >> of patches. But perhaps there'll be more by then too. >> > > I ran a comparison of trunk and 8.3 branch for x86_64 -m32, and got: > ... > $ diff -u <(grep ^FAIL: 8.3.m32/gdb.sum| sort) <(grep ^FAIL: > trunk.m32/gdb.sum|sort) | grep '^\-' > --- /dev/fd/63 2019-07-16 12:00:21.372197815 +0200 > -FAIL: gdb.base/catch-load.exp: plain unload: continue > -FAIL: gdb.base/catch-load.exp: rx unload: continue > -FAIL: gdb.base/info-shared.exp: info sharedlibrary #7 > -FAIL: gdb.base/info-shared.exp: info sharedlibrary #8 > -FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check > $_probe_arg1 for probe m4 > -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check > $_probe_arg1 for probe m4 > -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: print > $_probe_arg1 for probe ps > -FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check > $_probe_arg1 for probe m4 > -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check > $_probe_arg1 for probe m4 > -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: print > $_probe_arg1 for probe ps > -FAIL: gdb.base/unload.exp: continuing to unloaded libfile > -FAIL: gdb.base/unload.exp: continuing to unloaded libfile > -FAIL: gdb.base/unload.exp: continuing to unloaded libfile2 > -FAIL: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending > resolved: breakpoint on pendfunc3 pending again > -FAIL: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending > resolved: (timeout) > -FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop > ... > > The stap-probe.exp fix looks like 7d7571f0c1 "Adjust i386 registers on > SystemTap probes' arguments (PR breakpoints/24541)". > > If bisected the base/info-shared.exp fix to the same commit (which I did > not expect). This is because GDB uses SystemTap probes behind the scenes to deal with the linker-debugger interface. I don't have the logs here, but I'd guess there's something nasty going on because of the -m32 stap bug... > So I wonder if this commit is a good candidate to backport. I'd say so. The commit is simple enough, hasn't caused any regressions so far, and fixes a decent number of failures on -m32. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/