From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 05C0D385C017 for ; Tue, 31 Mar 2020 17:35:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05C0D385C017 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-GFTfA61aO4imcNXuGzsY3g-1; Tue, 31 Mar 2020 13:35:55 -0400 X-MC-Unique: GFTfA61aO4imcNXuGzsY3g-1 Received: by mail-ed1-f70.google.com with SMTP id b9so19169918edj.10 for ; Tue, 31 Mar 2020 10:35:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TdbEqgl38nqOiv9bHwP8ddc1EdO4U2NOBJ+faCcqCzk=; b=rjXA1kLCAFzd0n+4cNXh+7fMnxDPJBxHVpaVvuPFwrgXieGA4rShp8hoVf8FsxOVne OuJJzrgq8uOAWf9Z9gKK7X5pxEZvytEKvYxEKB/ND5MoojF/6944JobFoXVwqBdhmOLL M5VASNXJpw+SAZ+cNRH+w6uyBovgTWu9QJkzui7i/2nm2IJaeQITIMxc6tfEKya8bcaC 6HtghHSPNMPvQ8BUvH2wOQYno5v/2/b1tsgfVXpCMKx0THgDFsGTp/I0/lgtzPppFtvq jijpExijw5CSP4ty1cD4/KybZj88nguk0OJS4WYkfDdN2edYEcOldXTk+cOVuw06Z7WK 9C7g== X-Gm-Message-State: ANhLgQ3g4g3phbzrADSNN9ZUTXjB4A9dO3R9TwxNND7gC5pS7FsAsOOk nYl0JB9HHcjxGYHb7PsLXUpilvvVz/aJJwtpMMh9KCB+b6fyWVowLGwjFUEA7ptUMzKVtmeRMdo 7vvvKwezGd3VrIeh3ImaBiQ== X-Received: by 2002:a05:6402:3072:: with SMTP id bs18mr5223223edb.24.1585676153530; Tue, 31 Mar 2020 10:35:53 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtHKTwxcorAWQZDcGY6qsSgW6B9rJhzf+EQVnwyI8Xm5BrZRwzkIgFf4J+J8uFcHec6vco0bQ== X-Received: by 2002:a05:6402:3072:: with SMTP id bs18mr5223203edb.24.1585676153340; Tue, 31 Mar 2020 10:35:53 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id m3sm2275867ejj.22.2020.03.31.10.35.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2020 10:35:52 -0700 (PDT) Subject: Re: [RFC][gdb/testsuite] Fix silent timeout in gdb.multi/multi-target.exp To: Tom de Vries , gdb-patches@sourceware.org References: <20200316170131.GA20089@delia> From: Pedro Alves Message-ID: <54017f47-6b30-cb69-49c1-2c2bfd15a5d8@redhat.com> Date: Tue, 31 Mar 2020 18:35:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200316170131.GA20089@delia> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-23.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 31 Mar 2020 17:35:58 -0000 Hi, Thanks for addressing this, and sorry for the delay. On 3/16/20 5:01 PM, Tom de Vries wrote: > Hi, > > While running test-case gdb.multi/multi-target.exp, I observed a silent > timeout related to "monitor exit". > > By making the timeout explicit in an expect clause in gdbserver_gdb_exit: > ... > + timeout { > + warning "Timed out waiting for EOF in server after $monitor_exit" > + } > ... > we get in the log: > ... > monitor exit^M > "monitor" command not supported by this target.^M > (gdb) WARNING: Timed out waiting for EOF in server after monitor exit > ... > > What happens is the following: > - the inferior 5 is selected > - a breakpoint is set in inferior 1 > - the breakpoint triggers and we switch to inferior 1 > - setup is called by test_continue, which calls clean_restarts, which calls Typo: clean_restarts -> clean_restart > gdbserver_gdb_exit (due to load_lib gdbserver-support.exp) > - gdbserver_gdb_exit issues "monitor exit" > - gdb responds with "not supported by this target" because inferior 1 is > native > > Fix this by keeping a list of server_spawn_id, and cleaning those up before > calling gdbserver_gdb_exit. > > This reduces testing time from 1m22s to 32s. > > Any comments? Looks mostly good to me, though I have a comment below. > diff --git a/gdb/testsuite/gdb.multi/multi-target.exp b/gdb/testsuite/gdb.multi/multi-target.exp > index 6c727b5e3b..2e66cb55fa 100644 > --- a/gdb/testsuite/gdb.multi/multi-target.exp > +++ b/gdb/testsuite/gdb.multi/multi-target.exp > @@ -33,8 +33,13 @@ if { [prepare_for_testing "failed to prepare" ${binfile} "${srcfile}" \ > return > } > > +# Keep list of server_spawn_id > +set server_spawn_ids [list] It'd not a huge deal, but how about making this a list of pairs of (inferior ID, spawn ID)? That would make cleanup_gdbservers not have to hardcode the inferior numbers. add_inferior, which is connect_target_extended_remote's caller, has the inferior number handy already in the NUM parameter, so it'd just need to pass it down to connect_target_extended_remote. Thanks, Pedro Alves