From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 55CB23851C3A for ; Wed, 16 Sep 2020 10:59:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 55CB23851C3A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wm1-f49.google.com with SMTP id w2so2332650wmi.1 for ; Wed, 16 Sep 2020 03:59:39 -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=VNEyAczf2czICXB0eRXKqwq4IcQwdE/9GlhF7/kKo0Y=; b=ajSq2R/GLt6vmDtQtDrW/QqA5XuGL7k2nDwNz3knaYImBirWwMjqr7c3TzcTzg4Epy Ag3dqFf2OGev7GeMRc0zLBuqP0Sv1uQT1P0J/OUH1JY+u/wO6pa5oHxH59YLSrZ0tImX daEvmposSK0tmozgVgEEqwmVC31IxeD8IHryzzXlFO3WGs1dkZl1ec8VQn8CIu3bQqNV TOo0oka+4Rm6mWLG6p+UnQ8StJXzL7rL1l95ykf+jCg0mJsLPRz6mVB8rE+Wi3Buawpc eU+1YjDICfZfyaYEYecUyR3HwyLcbVQ7ENONuktA/+o2o4TILBAelPfWf1Nsrxm2DgQR YVww== X-Gm-Message-State: AOAM530OEOQCXGxrMwrmRVDsjYtvr7qjwHPVHURRIBU77Hrkxw+aCRvz He/tQh4eUsKHdrcYtjLuVkgFZ2eQJdB//A== X-Google-Smtp-Source: ABdhPJzfCJ5AkzB43816PwjMDqYtrAr4mzxj5ZUalW8QYwpXfpZlvOltUV60g5zPTiyp/sfUuyG6tg== X-Received: by 2002:a05:600c:ce:: with SMTP id u14mr4223772wmm.137.1600253976743; Wed, 16 Sep 2020 03:59:36 -0700 (PDT) Received: from ?IPv6:2001:8a0:f905:5600:eefd:c63:53e0:3e8a? ([2001:8a0:f905:5600:eefd:c63:53e0:3e8a]) by smtp.gmail.com with ESMTPSA id t22sm5594878wmt.1.2020.09.16.03.59.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2020 03:59:35 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Detect gdb prompt after monitor exit To: Tom de Vries , gdb-patches@sourceware.org References: <20200914192152.GA18245@delia> <4c088e4f-0c8d-62da-215e-b7062296cb33@palves.net> <2bdf800f-1f54-871c-0769-e833873cc099@suse.de> From: Pedro Alves Message-ID: <98ef5ad6-3a12-7dc9-1561-b46758f39c8f@palves.net> Date: Wed, 16 Sep 2020 11:59:34 +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: <2bdf800f-1f54-871c-0769-e833873cc099@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 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=no 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: Wed, 16 Sep 2020 10:59:40 -0000 On 9/15/20 3:17 PM, Tom de Vries wrote: > Anyway, this seems to work: > ... > index a2cc80f28d..24733275ae 100644 > --- a/gdb/testsuite/lib/gdbserver-support.exp > +++ b/gdb/testsuite/lib/gdbserver-support.exp > @@ -451,13 +451,20 @@ proc gdbserver_exit { is_mi } { > # We use expect rather than gdb_expect because > # we want to suppress printing exception messages, otherwise, > # remote_expect, invoked by gdb_expect, prints the exceptions. > + set have_prompt 0 > expect { > -i "$gdb_spawn_id" -re "$gdb_prompt $" { > - exp_continue > + if { [info exists server_spawn_id] } { > + set have_prompt 1 I'd put this "set have_prompt 1" outside of the if, seems would read clearer to me. Otherwise LGTM. > + exp_continue > + } > } > -i "$server_spawn_id" eof { > wait -i $expect_out(spawn_id) > unset server_spawn_id > + if { ! $have_prompt } { > + exp_continue > + } > } > timeout { > warning "Timed out waiting for EOF in server after > $monitor_exit" > ... > > I do wonder though about unsetting server_spawn_id and doing > exp_continue while we still have the clause -i $server_spawn_id eof. I > wonder this is supported behaviour. I'm not super sure, but I think it is, in that I don't think the -i expression is reevaluated after exp_continue. For example, this works: $ cat exp.exp set fake_spawn_id foo expect { -re "foo" { puts " got foo" if [info exists fake_spawn_id] { puts " unset" unset fake_spawn_id } exp_continue } -i "$fake_spawn_id" -re "bar" { puts " got bar?" } } $ expect exp.exp foo got foo unset foo got foo foo got foo bar foo got foo If it turns out to be an issue, we can always use an indirect spawn id instead: "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. " Pedro Alves