From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by sourceware.org (Postfix) with ESMTPS id 1F889385842B for ; Wed, 27 Apr 2022 18:42:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F889385842B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f46.google.com with SMTP id v12so3697890wrv.10 for ; Wed, 27 Apr 2022 11:42:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=6PRHQ3JZmEjVBSOAgAWlrk8ktyhf7ceKstxOdCMuJWo=; b=BG+yx6pm6pH/7iHgC0PpRmqSUg4gtSytHNDsUf+Nih4PFY99oOSmnwfTGwV6qltl5N C7DLa7z2DY0R+kN6zixG4F3Jbrrk0G2ztQ2KIJQPfENgg7gogxCWtvrbo5cLderBL5OJ R0OP430X0S5XurLgIlikHUG5yYUb/jDJfMsLjnhgys4CHQxu61QF2F4r6SnQ4CWAm1Ck 6OxLc0IfJt9CA6Cz76pxM5ujGo/VgLCHak75C0uptPPl4NU/HlEJU1Bf2vcc6NxzawnD me1TimL4ZTF3uMFKLo3ErwKRycSi/pMUlZUFBW/RfBjj/5J6I9WgoEFV0VIMJIgLnxzP J7Xg== X-Gm-Message-State: AOAM532TKwyBnBCfLDloMPP6XtwxsCSUeuIVnsMUmy5gA4O8OoQS2lfK mKN14cZDmQoow1mO9yS4xm8fb3pKnSo= X-Google-Smtp-Source: ABdhPJxckesj1evZdrT3xnCus9DsUlGaCg8Mze5BropGG4CFbX8jSrtjCvisCmq7oktM4oXosF19fA== X-Received: by 2002:a5d:5051:0:b0:20a:e005:cca3 with SMTP id h17-20020a5d5051000000b0020ae005cca3mr10412839wrt.560.1651084970049; Wed, 27 Apr 2022 11:42:50 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id b11-20020adfc74b000000b0020ad84d3fa3sm10019911wrh.44.2022.04.27.11.42.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Apr 2022 11:42:49 -0700 (PDT) Message-ID: Date: Wed, 27 Apr 2022 19:42:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH 1/2] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <7e541f1c625c73f20694ac37f3c326e57f95c11d.1651083290.git.aburgess@redhat.com> From: Pedro Alves In-Reply-To: <7e541f1c625c73f20694ac37f3c326e57f95c11d.1651083290.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 18:42:55 -0000 On 2022-04-27 19:17, Andrew Burgess via Gdb-patches wrote: > When running the gdb.mi/mi-exec-run.exp test using the > native-extended-gdbserver I see failures like this: > > FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected > FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected > FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected > > There's a race condition here, so you might see a slightly different > set of failures, but I always see some from the 'run failure detected' > test. > > NOTE: I also see an additional test failure: > > FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) > > but that is a completely different issue, and is not being addressed > in this commit. > > The problem for the 'run failure detected' test is that we end up > in gdb_expect looking for output from two spawn-ids, one from > gdbserver, and one from gdb. We're looking for one output pattern > from each spawn-id, and for the test to pass we need to see both > patterns. > > Now, if gdb exits then this is a test failure (this would indicate gdb > crashing, which is bad), so we have the eof pattern associated with > the gdb spawn-id. > > However, in this particular test we expect gdbserver to fail to > execute the binary (the test binary is set non-executable), and so we > get an error message from gdbserver (which matches the pattern), and > then gdbserver exits, this is expected. > > In our gdb_expect call we don't have an eof pattern for gdbserver, and > so, when gdbserver exits, expect sees eof and drops out of the > gdb_expect call. > > If both the gdbserver AND gdb patterns are seen before the gdbserver > eof triggers then everything is fine. > > But, if expect sees gdbserver's eof before seeing the output from gdb > then we will exit the gdb_expect call, and (as we have not seen both > patterns) we will call 'fail'. > > I initially tried to fix this by adding a new eof pattern for the > gdbserver spawn-id that called exp_continue, however, this causes > expect to throw an error, it is not happy to have '-i' options that > make use of a closed spawn-id. > I suspect this will look simpler if you use an indirect spawd id. Did you try that? >From the expect man page: "The -i flag may also name a global variable in which case the variable is read for a list of spawn ids. The variable is reread whenever it changes. This provides a way of changing the I/O source while the command is in execution. Spawn ids provided this way are called "indirect" spawn ids." Some other testcases use this technique to handle scenarios similar to what you describe, of not wanting to expect output out of a spawn_id anymore. E.g., gdb.base/interrupt.exp has: set spawn_list "$inferior_spawn_id" gdb_test_multiple "" $msg { -i spawn_list -re "end of file" { set saw_end_of_file 1 verbose -log "saw \"end of file\"" if {!$saw_inferior_exit} { # When $inferior_spawn_id != $gdb_spawn_id, such # as when testing with gdbserver, we may see the # eof (the process exit, not the string just # matched) for $inferior_spawn_id before the # expected gdb output. Clear this so we no longer # expect anything out of $inferior_spawn_id. set spawn_list "" exp_continue } } [...]