From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33114 invoked by alias); 4 Sep 2019 16:43:42 -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 33103 invoked by uid 89); 4 Sep 2019 16:43:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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; Wed, 04 Sep 2019 16:43:27 +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 6EE55C002966; Wed, 4 Sep 2019 16:43:26 +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 1FCE85D704; Wed, 4 Sep 2019 16:43:26 +0000 (UTC) From: Sergio Durigan Junior To: Tom de Vries Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) References: <20190714175240.GA23822@adacore.com> <877e7i3vpr.fsf@redhat.com> <2b220c6a-e212-65b0-e6e6-f668602179c6@suse.de> <31f1ccbe-535f-1f69-9ba8-e51a9a8e8a12@suse.de> Date: Wed, 04 Sep 2019 16:43:00 -0000 In-Reply-To: <31f1ccbe-535f-1f69-9ba8-e51a9a8e8a12@suse.de> (Tom de Vries's message of "Wed, 4 Sep 2019 10:19:12 +0200") Message-ID: <87r24wt3ki.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-09/txt/msg00029.txt.bz2 On Wednesday, September 04 2019, Tom de Vries wrote: > On 21-08-19 11:11, Tom de Vries wrote: >> [ was: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) ] >> >> On 12-08-19 23:44, Sergio Durigan Junior wrote: >>> On Tuesday, July 16 2019, Tom de Vries wrote: >> >>>> 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. >> >> The patch does not apply cleanly on gdb-8.3-branch, but it does if I >> first apply commit 677052f2a5 (Make >> stap-probe.c:stap_parse_register_operand's "regname" an std::string). >> >> I've tested the two commits on top of gdb-8.3-branch for x86_64-linux >> with unix/-m32 target board. >> >> No regression, and these progressions: >> ... >> -FAIL: gdb.base/catch-load.exp: plain unload: continue >> +PASS: gdb.base/catch-load.exp: plain unload: continue >> -FAIL: gdb.base/catch-load.exp: rx unload: continue >> +PASS: gdb.base/catch-load.exp: rx unload: continue >> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #7 >> +PASS: gdb.base/info-shared.exp: info sharedlibrary #7 >> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #8 >> +PASS: gdb.base/info-shared.exp: info sharedlibrary #8 >> -FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check >> $_probe_arg1 for probe m4 >> +PASS: gdb.base/stap-probe.exp: without semaphore, not optimized: check >> $_probe_arg1 for probe m4 >> -FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check >> $_probe_arg1 for probe m4 >> +PASS: gdb.base/stap-probe.exp: with semaphore, not optimized: check >> $_probe_arg1 for probe m4 >> -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check >> $_probe_arg1 for probe m4 >> +PASS: 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 >> +PASS: gdb.base/stap-probe.exp: without semaphore, optimized: print >> $_probe_arg1 for probe ps >> -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check >> $_probe_arg1 for probe m4 >> +PASS: 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 >> +PASS: gdb.base/stap-probe.exp: with semaphore, optimized: print >> $_probe_arg1 for probe ps >> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile >> +PASS: gdb.base/unload.exp: continuing to unloaded libfile >> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile >> +PASS: gdb.base/unload.exp: continuing to unloaded libfile >> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile2 >> +PASS: 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) >> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending >> resolved: breakpoint on pendfunc3 pending again >> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending >> resolved: >> -FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop >> +PASS: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop >> -# of expected passes 65957 >> -# of unexpected failures 235 >> +# of expected passes 65973 >> +# of unexpected failures 219 >> ... >> >> OK to backport both commits to gdb-8.3-branch? > > Ping. I'm the maintainer of the SystemTap/generic probe interfaces, but I'm not sure I can give you the green light for you in this case, because it's about backporting to a branch. In any case, just to make sure I'm clear: this one LGTM. 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/