From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id E625E3858D20 for ; Thu, 3 Mar 2022 18:45:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E625E3858D20 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-wm1-f53.google.com with SMTP id k29-20020a05600c1c9d00b003817fdc0f00so3782491wms.4 for ; Thu, 03 Mar 2022 10:45:16 -0800 (PST) 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=IUk3Rr3tUGqOTQlMyz2EBl+4IYmrQSN4pLnmyFHdmz0=; b=XNa8RH5/CuzsMqP7BEvoGZCl5CVeDj++INcZmZo2oVdje3EVxHQmP4sGJ7kXFbfRHh Rph5hfJzw4IQe4whFq31scnGh3e4O4lUlLaMxtXdaRJwvpEwraupLi1rXxPVGYvqGWUT uIz893m4Znd1xugMMIOIC7DrJO7Ko1yR8DxF0KPeluT5Gpxk2ilHAt1Dp2QfYmHKvjij i4Ra8myZlNo/57xDAqLDm1TcQeUiNHrZHxDzLIgVHMGWMm1Mq3o4HKy6GHeKJjaUVgwR 30PkEnEZeH0A6pgJ9jem/OLolMnfknk/CWaLS4czPBzcvkhQP15D3dF1Ki5mGAv+eGtI OaQw== X-Gm-Message-State: AOAM532M/xe2/Pr6pVMHaXyTQoy8ppdpkybUEIf36XTXa7uIUIIRjXmU YnM26Um0ZWuj2XstGX0UhhbEv8eSV4E= X-Google-Smtp-Source: ABdhPJyHeq81U/YCYkEn3ZGEGVcuHIg8I59PyWiDC5ouPO3BNrIlZglGheCN8QhkJoIRv2T+rhOcEA== X-Received: by 2002:a7b:cb83:0:b0:37e:bc50:3c6b with SMTP id m3-20020a7bcb83000000b0037ebc503c6bmr4810100wmi.67.1646333115870; Thu, 03 Mar 2022 10:45:15 -0800 (PST) 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 l18-20020adfe592000000b001f064ae9830sm978765wrm.37.2022.03.03.10.45.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Mar 2022 10:45:14 -0800 (PST) Message-ID: Date: Thu, 3 Mar 2022 18:45:13 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH v5 2/2] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp Content-Language: en-US To: Tiezhu Yang , gdb-patches@sourceware.org References: <1645584316-5375-1-git-send-email-yangtiezhu@loongson.cn> <1645584316-5375-3-git-send-email-yangtiezhu@loongson.cn> From: Pedro Alves In-Reply-To: <1645584316-5375-3-git-send-email-yangtiezhu@loongson.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 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, T_SCC_BODY_TEXT_LINE autolearn=no 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: Thu, 03 Mar 2022 18:45:18 -0000 On 2022-02-23 02:45, Tiezhu Yang wrote: > -proc can_spawn_for_attach { } { > +gdb_caching_proc can_spawn_for_attach { > # We use exp_pid to get the inferior's pid, assuming that gives > # back the pid of the program. On remote boards, that would give > # us instead the PID of e.g., the ssh client, etc. > @@ -5079,6 +5079,42 @@ proc can_spawn_for_attach { } { > return 0 > } > > + set me "can_spawn_for_attach" > + set src { int main (void) { sleep (600); return 0; } } > + if {![gdb_simple_compile $me $src executable]} { > + return 0 > + } > + > + set test_spawn_id [spawn_wait_for_attach $obj] > + set test_pid [spawn_id_get_pid $test_spawn_id] > + > + gdb_start > + file delete $obj > + gdb_test_multiple "attach $test_pid" "can spawn for attach" { > + -re -wrap "Attaching to process $test_pid\r\n.*No executable file now.*" { > + pass $gdb_test_name I don't think caching procs should issue pass/fail, as whether the proc does anything depends on whether the result was cached before. It seems weird to get a PASS/FAIL depending on whether the result was cached or not earlier. > + kill_wait_spawned_process $test_spawn_id > + return 1 I have to say this whole thing seems completely backwards to me. We are checking whether we can spawn a program for attaching, by spawning a program for attaching, and then attaching... If the "attach" command has some kind of bug, then we will fail can_spawn_for_attach instead of having that proc return true, and then letting the proper "attach" tests fail. Why isn't this all solved by leaving can_spawn_for_attach alone, and then making the "attach" tests bail out on failure to attach. We could add some new gdb_attach proc to centralize the failure checking.