Message ID | 20220923141801.1106678-1-simon.marchi@polymtl.ca |
---|---|
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E05963857034 for <patchwork@sourceware.org>; Fri, 23 Sep 2022 14:18:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E05963857034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663942711; bh=1A+8x8u4Fyytzs1ISXn6t1Ty30rF5kJkzAXGpQUAMS0=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=R8OE0EzaSiKe1dTzVPYgNnjvtX9cKzSvkLlR+C0UpTZM3Kaf4o+1ELp8woXHLiC3a rDAX3HxyLZKOebpMmte8LHG6OebdX9bav3TsgHO+01im460g5elkPmfYvCru8eT/0W 9OXvVL3MnkpLeHkWWHb8FfGd23L2GvWb69bADp6Y= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 7A5AF3857B8D for <gdb-patches@sourceware.org>; Fri, 23 Sep 2022 14:18:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A5AF3857B8D Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 28NEI2gQ001480 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Sep 2022 10:18:07 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 28NEI2gQ001480 Received: from simark.localdomain (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B58A51E0D3; Fri, 23 Sep 2022 10:18:02 -0400 (EDT) To: gdb-patches@sourceware.org Subject: [PATCH 0/3] Fix gdb.gdb/python-helper.exp + cleanups Date: Fri, 23 Sep 2022 10:17:58 -0400 Message-Id: <20220923141801.1106678-1-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 23 Sep 2022 14:18:02 +0000 X-Spam-Status: No, score=-3184.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Simon Marchi <simon.marchi@polymtl.ca> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Fix gdb.gdb/python-helper.exp + cleanups
|
|
Message
Simon Marchi
Sept. 23, 2022, 2:17 p.m. UTC
My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused regressions in gdb.gdb/python-helper.exp. I forgot to update gdb-gdb.py.in, as always. It looks like my CI doesn't run the test properly. Because inserting the first breakpoint times out, do_self_tests skips the test. I also had troubles running the test locally due to these timeouts. So the first two patches address problems related to that, and the third one is the actual fix. Simon Marchi (3): gdb/testsuite: bump duration for the whole test in do_self_tests gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp gdb/testsuite: update field names in gdb-gdb.py.in gdb/gdb-gdb.py.in | 4 +- gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- gdb/testsuite/lib/gdb.exp | 8 +-- gdb/testsuite/lib/selftest-support.exp | 36 +++------- 4 files changed, 31 insertions(+), 105 deletions(-) base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956
Comments
On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: > My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused > regressions in gdb.gdb/python-helper.exp. I forgot to update > gdb-gdb.py.in, as always. > > It looks like my CI doesn't run the test properly. Because inserting the > first breakpoint times out, do_self_tests skips the test. I also had > troubles running the test locally due to these timeouts. So the first > two patches address problems related to that, and the third one is the > actual fix. > > Simon Marchi (3): > gdb/testsuite: bump duration for the whole test in do_self_tests > gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp > gdb/testsuite: update field names in gdb-gdb.py.in > > gdb/gdb-gdb.py.in | 4 +- > gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- > gdb/testsuite/lib/gdb.exp | 8 +-- > gdb/testsuite/lib/selftest-support.exp | 36 +++------- > 4 files changed, 31 insertions(+), 105 deletions(-) > > > base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 Thanks for the series. I tested this on my end and it seems to work nicely. The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe it is a problem with guile and armhf. I don't think it is a flaw with the patch though. We'd have to go out of our way to handle something like this in the testcase. So this series LGTM.
On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: > On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >> regressions in gdb.gdb/python-helper.exp. I forgot to update >> gdb-gdb.py.in, as always. >> >> It looks like my CI doesn't run the test properly. Because inserting the >> first breakpoint times out, do_self_tests skips the test. I also had >> troubles running the test locally due to these timeouts. So the first >> two patches address problems related to that, and the third one is the >> actual fix. >> >> Simon Marchi (3): >> gdb/testsuite: bump duration for the whole test in do_self_tests >> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >> gdb/testsuite: update field names in gdb-gdb.py.in >> >> gdb/gdb-gdb.py.in | 4 +- >> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >> gdb/testsuite/lib/gdb.exp | 8 +-- >> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >> 4 files changed, 31 insertions(+), 105 deletions(-) >> >> >> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 > > Thanks for the series. I tested this on my end and it seems to work nicely. > > The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile > interpreter hitting GC_find_limit_with_bound. I'm not sure why this > happens. Maybe > it is a problem with guile and armhf. It's documented behaviour of libgc1, see https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . Thanks, - Tom > > I don't think it is a flaw with the patch though. We'd have to go out of > our way > to handle something like this in the testcase. > > So this series LGTM.
On 2022-09-23 17:35, Tom de Vries wrote: > On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: >> On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >>> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >>> regressions in gdb.gdb/python-helper.exp. I forgot to update >>> gdb-gdb.py.in, as always. >>> >>> It looks like my CI doesn't run the test properly. Because inserting the >>> first breakpoint times out, do_self_tests skips the test. I also had >>> troubles running the test locally due to these timeouts. So the first >>> two patches address problems related to that, and the third one is the >>> actual fix. >>> >>> Simon Marchi (3): >>> gdb/testsuite: bump duration for the whole test in do_self_tests >>> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >>> gdb/testsuite: update field names in gdb-gdb.py.in >>> >>> gdb/gdb-gdb.py.in | 4 +- >>> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >>> gdb/testsuite/lib/gdb.exp | 8 +-- >>> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >>> 4 files changed, 31 insertions(+), 105 deletions(-) >>> >>> >>> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 >> >> Thanks for the series. I tested this on my end and it seems to work nicely. >> >> The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile >> interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe >> it is a problem with guile and armhf. > > It's documented behaviour of libgc1, see > https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . Ack, this is an orthogonal issue (and for some reason I don't see it on my Arch Linux, but I have certainly seen it elsewhere). Just to confirm, does the series look good to you too Tom? Simon
On 9/26/22 20:01, Simon Marchi wrote: > > > On 2022-09-23 17:35, Tom de Vries wrote: >> On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: >>> On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >>>> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >>>> regressions in gdb.gdb/python-helper.exp. I forgot to update >>>> gdb-gdb.py.in, as always. >>>> >>>> It looks like my CI doesn't run the test properly. Because inserting the >>>> first breakpoint times out, do_self_tests skips the test. I also had >>>> troubles running the test locally due to these timeouts. So the first >>>> two patches address problems related to that, and the third one is the >>>> actual fix. >>>> >>>> Simon Marchi (3): >>>> gdb/testsuite: bump duration for the whole test in do_self_tests >>>> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >>>> gdb/testsuite: update field names in gdb-gdb.py.in >>>> >>>> gdb/gdb-gdb.py.in | 4 +- >>>> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >>>> gdb/testsuite/lib/gdb.exp | 8 +-- >>>> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >>>> 4 files changed, 31 insertions(+), 105 deletions(-) >>>> >>>> >>>> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 >>> >>> Thanks for the series. I tested this on my end and it seems to work nicely. >>> >>> The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile >>> interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe >>> it is a problem with guile and armhf. >> >> It's documented behaviour of libgc1, see >> https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . > > Ack, this is an orthogonal issue (and for some reason I don't see it on > my Arch Linux, but I have certainly seen it elsewhere). > > Just to confirm, does the series look good to you too Tom? > Hi Simon, it does, yes, thanks. I did wonder a bit about the first patch, where we remove the whole bit about the 5 minute timeout, but after thinking a bit on this I realized that setting absolute timeouts like that are likely to be inaccurate, so replacing it with a relative one (timeout factor) is better. The quoted example is likely to have an in increased timeout in the board settings anyway, so that could partially take care of the drop in timeout from 5m (600s) to 10 (timeout factor) * 10s (100s). Anyway, I tested the series and it takes care of the regression for me. Thanks, - Tom
On 2022-09-26 14:39, Tom de Vries wrote: > On 9/26/22 20:01, Simon Marchi wrote: >> >> >> On 2022-09-23 17:35, Tom de Vries wrote: >>> On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: >>>> On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >>>>> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >>>>> regressions in gdb.gdb/python-helper.exp. I forgot to update >>>>> gdb-gdb.py.in, as always. >>>>> >>>>> It looks like my CI doesn't run the test properly. Because inserting the >>>>> first breakpoint times out, do_self_tests skips the test. I also had >>>>> troubles running the test locally due to these timeouts. So the first >>>>> two patches address problems related to that, and the third one is the >>>>> actual fix. >>>>> >>>>> Simon Marchi (3): >>>>> gdb/testsuite: bump duration for the whole test in do_self_tests >>>>> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >>>>> gdb/testsuite: update field names in gdb-gdb.py.in >>>>> >>>>> gdb/gdb-gdb.py.in | 4 +- >>>>> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >>>>> gdb/testsuite/lib/gdb.exp | 8 +-- >>>>> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >>>>> 4 files changed, 31 insertions(+), 105 deletions(-) >>>>> >>>>> >>>>> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 >>>> >>>> Thanks for the series. I tested this on my end and it seems to work nicely. >>>> >>>> The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile >>>> interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe >>>> it is a problem with guile and armhf. >>> >>> It's documented behaviour of libgc1, see >>> https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . >> >> Ack, this is an orthogonal issue (and for some reason I don't see it on >> my Arch Linux, but I have certainly seen it elsewhere). >> >> Just to confirm, does the series look good to you too Tom? >> > > Hi Simon, > > it does, yes, thanks. > > I did wonder a bit about the first patch, where we remove the whole bit about the 5 minute timeout, but after thinking a bit on this I realized that setting absolute timeouts like that are likely to be inaccurate, so replacing it with a relative one (timeout factor) is better. The quoted example is likely to have an in increased timeout in the board settings anyway, so that could partially take care of the drop in timeout from 5m (600s) to 10 (timeout factor) * 10s (100s). Yeah, that was my thinking: if it's a slow board, it will have some increased timeout already, and that will be multiplied by 10. This is better than one hard-coded value added 20 years ago for some specific board. > Anyway, I tested the series and it takes care of the regression for me. Thanks, will push. Simon
On 26/09/2022 20:01, Simon Marchi via Gdb-patches wrote: > > On 2022-09-23 17:35, Tom de Vries wrote: >> On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: >>> On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >>>> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >>>> regressions in gdb.gdb/python-helper.exp. I forgot to update >>>> gdb-gdb.py.in, as always. >>>> >>>> It looks like my CI doesn't run the test properly. Because inserting the >>>> first breakpoint times out, do_self_tests skips the test. I also had >>>> troubles running the test locally due to these timeouts. So the first >>>> two patches address problems related to that, and the third one is the >>>> actual fix. >>>> >>>> Simon Marchi (3): >>>> gdb/testsuite: bump duration for the whole test in do_self_tests >>>> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >>>> gdb/testsuite: update field names in gdb-gdb.py.in >>>> >>>> gdb/gdb-gdb.py.in | 4 +- >>>> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >>>> gdb/testsuite/lib/gdb.exp | 8 +-- >>>> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >>>> 4 files changed, 31 insertions(+), 105 deletions(-) >>>> >>>> >>>> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 >>> Thanks for the series. I tested this on my end and it seems to work nicely. >>> >>> The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile >>> interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe >>> it is a problem with guile and armhf. >> It's documented behaviour of libgc1, see >> https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . > Ack, this is an orthogonal issue (and for some reason I don't see it on > my Arch Linux, but I have certainly seen it elsewhere). This bug happens because of an old version of libgc being used, where they used that segfault to probe memory for something. They have developed a new way of probing that doesn't trigger this segfault, but not all distributions seem to have backported it. It's probably not happening on Arch because htey have a new version of the library, while on fedora it was happening until recently (Alexandra backported that for us). Fixing this sort of needs to happen on a per-distro basis, as it isn't GDB related, it's an "available libraries" problem. Cheers, Bruno > > Just to confirm, does the series look good to you too Tom? > > Simon >
On 9/27/22 11:34, Bruno Larsen wrote: > On 26/09/2022 20:01, Simon Marchi via Gdb-patches wrote: >> >> On 2022-09-23 17:35, Tom de Vries wrote: >>> On 9/23/22 19:02, Luis Machado via Gdb-patches wrote: >>>> On 9/23/22 15:17, Simon Marchi via Gdb-patches wrote: >>>>> My patches that touched TYPE_LENGTH and TYPE_TARGET_TYPE caused >>>>> regressions in gdb.gdb/python-helper.exp. I forgot to update >>>>> gdb-gdb.py.in, as always. >>>>> >>>>> It looks like my CI doesn't run the test properly. Because inserting the >>>>> first breakpoint times out, do_self_tests skips the test. I also had >>>>> troubles running the test locally due to these timeouts. So the first >>>>> two patches address problems related to that, and the third one is the >>>>> actual fix. >>>>> >>>>> Simon Marchi (3): >>>>> gdb/testsuite: bump duration for the whole test in do_self_tests >>>>> gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp >>>>> gdb/testsuite: update field names in gdb-gdb.py.in >>>>> >>>>> gdb/gdb-gdb.py.in | 4 +- >>>>> gdb/testsuite/gdb.gdb/python-helper.exp | 88 +++++-------------------- >>>>> gdb/testsuite/lib/gdb.exp | 8 +-- >>>>> gdb/testsuite/lib/selftest-support.exp | 36 +++------- >>>>> 4 files changed, 31 insertions(+), 105 deletions(-) >>>>> >>>>> >>>>> base-commit: 8e037eae6823caf5b9cb5b4feb3de838abb25956 >>>> Thanks for the series. I tested this on my end and it seems to work nicely. >>>> >>>> The only hiccup I noticed is when GDB runs into a SIGSEGV due to the guile >>>> interpreter hitting GC_find_limit_with_bound. I'm not sure why this happens. Maybe >>>> it is a problem with guile and armhf. >>> It's documented behaviour of libgc1, see >>> https://sourceware.org/bugzilla/show_bug.cgi?id=29325 . >> Ack, this is an orthogonal issue (and for some reason I don't see it on >> my Arch Linux, but I have certainly seen it elsewhere). > > This bug happens because of an old version of libgc being used, where they used that segfault to probe memory for something. They have developed a new way of probing that doesn't trigger this segfault, but not all distributions seem to have backported it. It's probably not happening on Arch because htey have a new version of the library, while on fedora it was happening until recently (Alexandra backported that for us). Fixing this sort of needs to happen on a per-distro basis, as it isn't GDB related, it's an "available libraries" problem. Thanks for the tip. I'll try to update the packages for this particular distro (Ubuntu 22.04). > > Cheers, > Bruno > >> >> Just to confirm, does the series look good to you too Tom? >> >> Simon >> >