From: Pedro Alves <palves@redhat.com>
To: Alan Hayward <Alan.Hayward@arm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: nd <nd@arm.com>
Subject: Re: [PATCH] testsuite: disable break-interp.exp for Arm buildbot
Date: Fri, 09 Aug 2019 17:22:00 -0000 [thread overview]
Message-ID: <abb5717f-91d5-7be0-2457-3f46de87324e@redhat.com> (raw)
In-Reply-To: <20190809092128.94802-1-alan.hayward@arm.com>
On 8/9/19 10:21 AM, Alan Hayward wrote:
> Use this test to disable gdb.base/break-interp.exp,
I'd rather avoid completely skipping silently, since this way
nobody will ever remember to enable it back.
> as this test currently generates 132 sequential timeouts.
So, in the general case, when something like that happens, it's better
to make the testcase bail out earlier in response to one of the
failures. Like, if we fail to run to a breakpoint or something, then
there's no point in continuing the parts of the testcase that depend
on running to that breakpoint.
Is there some fundamental failures in each of the iterations of
the test that we could detect to skip most of the tests in each of
the iterations?
From your mention of "fix stop on solib" not working, it sounds like the
trouble is that when the testcase does "set stop-on-solib-events 1 + run",
the inferior never stops and we time out. Can you make reach_1 detect it
and bail out without waiting for a time out? Like, make the testcase
put a breakpoint somewhere in case stop-on-solib-events fails to stop
the inferior.
That'd be better since it'd record the FAILs, and it would be target
independent.
Some minor comments below.
> diff --git a/gdb/testsuite/gdb.base/break-interp.exp b/gdb/testsuite/gdb.base/break-interp.exp
> index d6da653529..6a366db49f 100644
> --- a/gdb/testsuite/gdb.base/break-interp.exp
> +++ b/gdb/testsuite/gdb.base/break-interp.exp
> @@ -15,7 +15,8 @@
>
> # This test only works on GNU/Linux.
> if { ![isnative] || [is_remote host] || [use_gdb_stub]
> - || ![istarget *-linux*] || [skip_shlib_tests]} {
> + || ![istarget *-linux*] || [skip_shlib_tests]
> + || [is_aarch32_on_aarch64_target]} {
> continue
> }
ENOCOMMENTS.
>
> diff --git a/gdb/testsuite/lib/future.exp b/gdb/testsuite/lib/future.exp
> index 122e652858..d43dd95904 100644
> --- a/gdb/testsuite/lib/future.exp
> +++ b/gdb/testsuite/lib/future.exp
> @@ -172,6 +172,16 @@ proc gdb_find_eu-unstrip {} {
> return $eu_unstrip
> }
>
> +proc gdb_find_uname {} {
> + global UNAME_FOR_TARGET
> + if [info exists UNAME_FOR_TARGET] {
> + set uname $UNAME_FOR_TARGET
> + } else {
> + set uname [transform uname]
> + }
> + return $uname
> +}
> +
Not sure this should be here. See the comment at the
top of the file.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2019-08-09 17:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 9:21 Alan Hayward
2019-08-09 17:22 ` Pedro Alves [this message]
2019-08-12 15:53 ` Alan Hayward
2019-08-15 17:49 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abb5717f-91d5-7be0-2457-3f46de87324e@redhat.com \
--to=palves@redhat.com \
--cc=Alan.Hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox