From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 6BE843889807 for ; Fri, 18 Mar 2022 18:33:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BE843889807 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-f50.google.com with SMTP id h129-20020a1c2187000000b0038c8b999f58so12799wmh.1 for ; Fri, 18 Mar 2022 11:33:07 -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:cc:references:from:in-reply-to :content-transfer-encoding; bh=XWaRIGIFvrZyvvCBPN3zlD53A0r2YpYbdjkq3bcLiR8=; b=zwfSwRv9UcrAbdE6AWCUoDozkmqMQrTqGCapbTEf8IkyWbW3j9JBd8RSLgVS2gqpMK cHmlR8+j3NsfNkD3wRHTvYPi21Vbyz5MfwCUi5niG5SYplqb87kJStIOmdK4LXFvTzZ7 Lf95uYj41NNbkZg2TPG7sLi2N9QahbMifqMnA3xhnuXmJPMPG15v0yaAaIc3QM/uO20q MuONFHnzOPX1b2Apfp/luuLyfaq1PIV/fTzOdUKxJmgxJ5EbPG21y3XU+Zq7iOpCAeeI DWByermOJFEECOZ01HDRjHPgDqDyBOzAbBsQTtxu+OQXmHBldnofQeve7DiucOj9J5SY 2SDQ== X-Gm-Message-State: AOAM5334qnKEgy7qgNMn6EFaHlxN+E5yDYGrNh0VBKyBVUrEyx1Vbuyz 5jObw1GmEWEBXgnPpFDzhf0= X-Google-Smtp-Source: ABdhPJy6JfMYvtWj6tVSNRq1nXVJ3gKkbzCymNUnWK/i4U5chAY15mNT6s6HrqKdKNwpOpjsORrndA== X-Received: by 2002:a1c:f312:0:b0:387:8bf:bd3 with SMTP id q18-20020a1cf312000000b0038708bf0bd3mr9022828wmq.112.1647628386234; Fri, 18 Mar 2022 11:33:06 -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 k12-20020a5d628c000000b00203e2fbb2absm6039956wru.113.2022.03.18.11.33.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 11:33:05 -0700 (PDT) Message-ID: Date: Fri, 18 Mar 2022 18:33:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v3 0/4] gdb: add gdb_attach to fix failed testcases Content-Language: en-US To: Tiezhu Yang , gdb-patches@sourceware.org References: <1647525661-8607-1-git-send-email-yangtiezhu@loongson.cn> <7807b618-33b2-1e6c-e618-bf477c2b145e@palves.net> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.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, 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: Fri, 18 Mar 2022 18:33:09 -0000 On 2022-03-18 01:53, Tiezhu Yang wrote: > > > On 03/18/2022 12:55 AM, Pedro Alves wrote: >> On 2022-03-17 14:00, Tiezhu Yang wrote: >>> Hi Simon and Pedro, >>> >>> Thank you very much for your suggestions. >>> Please review this v3 patchset. >>> Any comments will be much appreciated. >> >> Thanks for doing this. >> >> Are these really the only .exp files that need to use gdb_attach?  Or is it just >> that you're tackling this incrementally? >> > > At least for now, attach-pie-noexec.exp and jit-elf.exp need to use > gdb_attach to fix the failed testcases, if we find the other .exp > files also have similar issues in the future, I will tackling them > incrementally. On a first approximation, I'd think most of the tests that use can_spawn_for_attach would need to be adjusted. gdb.threads/detach-step-over.exp:51:if {![can_spawn_for_attach]} { gdb.threads/attach-many-short-lived-threads.exp:52:if {![can_spawn_for_attach]} { gdb.threads/clone-attach-detach.exp:26:if {![can_spawn_for_attach]} { gdb.threads/attach-non-stop.exp:22:if {![can_spawn_for_attach]} { gdb.base/attach.exp:16:if {![can_spawn_for_attach]} { gdb.base/kill-detach-inferiors-cmd.exp:21:if ![can_spawn_for_attach] { gdb.base/watchpoint-hw-attach.exp:23:if {![can_spawn_for_attach]} { gdb.base/solib-overlap.exp:34:if {![can_spawn_for_attach]} { gdb.base/random-signal.exp:70: if {[can_spawn_for_attach]} { gdb.base/jit-elf.exp:151:if {[can_spawn_for_attach]} { gdb.base/interrupt-daemon-attach.exp:27:if { ![can_spawn_for_attach] } { gdb.base/attach-non-pgrp-leader.exp:21:if {![can_spawn_for_attach]} { gdb.base/attach-pie-noexec.exp:16:if {![can_spawn_for_attach]} { gdb.base/corefile.exp:290: if [can_spawn_for_attach] { gdb.base/run-attach-while-running.exp:38: if { ${run-or-attach} == "attach" && ![can_spawn_for_attach] } { gdb.base/quit-live.exp:168: if {$appear_how != "run" && ![can_spawn_for_attach]} { gdb.base/attach-twice.exp:16:if {![can_spawn_for_attach]} { gdb.base/bp-cmds-continue-ctrl-c.exp:137: if {[can_spawn_for_attach]} { gdb.base/run-after-attach.exp:19:if ![can_spawn_for_attach] { gdb.base/jit-attach-pie.exp:16:if {![can_spawn_for_attach]} { gdb.python/py-sync-interp.exp:23:if {![can_spawn_for_attach]} { gdb.python/py-prompt.exp:81:if {![can_spawn_for_attach]} { gdb.server/attach-flag.exp:28:if {![can_spawn_for_attach]} { gdb.server/ext-attach.exp:29:if {![can_spawn_for_attach]} { gdb.multi/multi-attach.exp:22:if {![can_spawn_for_attach]} { gdb.multi/multi-term-settings.exp:28:if ![can_spawn_for_attach] { gdb.mi/list-thread-groups-available.exp:38:if ![can_spawn_for_attach] { My main "worry" (not very serious), is that we discover that some test is currently using gdb_test_multiple to expect more than one potential output after "attach ...", which can't be mapped to gdb_attach as is. That would suggest that gdb_attach would be better redesigned as a wrapper around gdb_test_multiple with some internal matches, rather than passing down the expected pattern with "-pattern". if ![!gdb_test_attach_multiple "attach 123" "testname" { -re -wrap "foo bar output 1" { pass "$gdb_test_name (v1)" } -re -wrap "foo bar output 2" { pass "$gdb_test_name (v2)" } }] { return } Maybe we'd call it gdb_test_attach_multiple, and then add a gdb_test_attach wrapper around it that would be just like gdb_test vs gdb_test_multiple. That would suggest that gdb_test_attach wouldn't be using options like "-pattern" at all.