From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by sourceware.org (Postfix) with ESMTPS id C98933857836 for ; Fri, 8 Apr 2022 12:18:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C98933857836 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-f48.google.com with SMTP id j5-20020a05600c1c0500b0038ea8b53580so639349wms.1 for ; Fri, 08 Apr 2022 05:18:39 -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=doS/tgz/kPLWRJg8/DsrIhloY/WAjCMf3Ee/3ITpf90=; b=xenGCkuk9LJsxbwUXmMdzqEc9DEOb6iXg9W88hq/omi0h3UP0F0s5UkLU1PtIdIa7e aHQodnmyfLSUVqos+i/cDDYw5DkKY9hT0pwUaVLSsM7p1nKvqwt79wnOOct7Roranucf FaD1wEWl/XsYE6s1O8CMSNUduZlYGGZ0MEyEEp+uxxP+2uHcOXHbks68x6QoU+JzfAZz AITp+hr3RcNpNmXDFSgun4H8Z71fJ5xJ94yfbNnwj8EsP0AKHDlq25LZKM2rb9cUFM8h +1XjMPOuIBjGk8H3wDgjDNiUpXNc6wC2A91jNAmXIxijBFOqceRgjEH2Y2qI8SvweeCU f/cA== X-Gm-Message-State: AOAM531fW2JUyQyGL+BcZtDj0842ctf49t63un0gjPkr4m554iksqPzH RtVHhG+GEHfoEuqr8U5C+U0= X-Google-Smtp-Source: ABdhPJzoxmVi5K9I64Z5pWW4CeCFDtMLgFl/XAdIs0T+vtWXeTZON2quwyjORTZVYIvQmqJX0T8v1w== X-Received: by 2002:a05:600c:1c9c:b0:38e:3270:373d with SMTP id k28-20020a05600c1c9c00b0038e3270373dmr16662535wms.199.1649420318524; Fri, 08 Apr 2022 05:18:38 -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 11-20020a056000156b00b002040674fd13sm23766674wrz.38.2022.04.08.05.18.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 05:18:37 -0700 (PDT) Message-ID: Date: Fri, 8 Apr 2022 13:18:31 +0100 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 5/5] Make gdb_test's question non-optional if specified Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <20220330192929.3161015-1-pedro@palves.net> <20220330192929.3161015-6-pedro@palves.net> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 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=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: Fri, 08 Apr 2022 12:18:43 -0000 On 2022-04-07 21:31, Bruno Larsen wrote: > On 3/30/22 16:29, Pedro Alves wrote: >> gdb_test supports handling scenarios where GDB asks a question before >> finishing handling some command.  The full prototype of gdb_test is: >> >>    # gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE >> >> However, QUESTION is a question that GDB _may_ ask, not one that GDB >> _must_ ask: >> >>   # QUESTION is a question GDB may ask in response to COMMAND, like >>   #   "are you sure?" >>   # RESPONSE is the response to send if QUESTION appears. >> >> If GDB doesn't raise the question, the test still passes. >> >> I think that this is a misfeature.  If GDB regresses and stops asking >> a question, the testsuite won't notice.  So I think that if a QUESTION >> is specified, gdb_test should ensure it comes out of GDB. > > I just ran into a neat use of this, or possibly a mis-use, depending on how much you like it. gdb.base/skip.exp uses: > > gdb_test "step" "desired spot" "go to desired spot" "undesirable spot" "step" > > as a simple way to handle a gcc 9.2.0 bug (misfeature) where gdb could stop in an undesirable spot without actually causing a failure in the test. This feels like a neat way to deal with compiler problems, as it would introduce a simple way to deal with clang's lack of epilogue, for instance. This is: # With gcc 9.2.0 we jump once back to main before entering foo here. # If that happens try to step a second time. gdb_test "step" "foo \\(\\) at.*" "step 3" \ "main \\(\\) at .*\r\n$gdb_prompt " "step" I think this is a misuse. That case doesn't really handle a GDB confirmation question. What if you need to issue more steps, or the program may stop elsewhere for different ports, and thus you need more than one regexp? For the latter you can use (REGEX1|REGEX1), but it isn't as nice as separate -re entries, IMHO. IMHO, writing it with gdb_test_multiple in these cases is OK: gdb_test_multiple "step" "step 3" { -re -wrap "foo \\(\\) at.*" { pass $gdb_test_multiple } -re -wrap "main \\(\\) at .*" { # With gcc 9.2.0 we jump once back to main before entering foo. # If that happens try another step. send_gdb "step\n" exp_continue } } It's a standard pattern we use in many places, I don't think it's bad enough that we need to hide it. > > I'm not suggesting that this patch be scrapped, but maybe this could be implemented on purpose, something like gdb_test_optional. The code itself LGTM, but I am not able to approve patches. >