From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id 64D4C3858420 for ; Wed, 2 Mar 2022 16:11:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 64D4C3858420 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-wr1-f42.google.com with SMTP id u10so1932265wra.9 for ; Wed, 02 Mar 2022 08:11:04 -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=of7hY+rLKhVzU7mulAcNkBrTaJGpCiSLa3MM7T7HbDQ=; b=vdhKyTMCnadWS4PPCPs8VjJ5jCFI0JzhhLtB9P0pLFPmR5UW2fMs/+M3DQSWxabM8o eXXB65Cx/jR22WlNY8VpOcZje3OlPeQwJ2uF831ZCC51LuCwPnedxnmCnqGLm2BqKB0W YHEci8Azbk2HljGeRIQhNLz/dAZhVCky5JMDQmXP3dtsYSS5gqY8MVem891TddVYf4TP j1L+8eUfTuxrwLZQzmqndL4uX6vEDmCBse8+n6A0mERTJGnUwDucdAfE1pTPz9l/8TfC uyo3YVVD8yIK4a+Ub3dhlKErs0xwEABrXen64bF6Be7yISkD9qunysXICi2afMIajovQ fuMg== X-Gm-Message-State: AOAM531W6vhxnHHcUIpVRT/89iAko+Yj6B3QrVzoEr4hb6Qt2raoMbFe gQBmlEja1XHFeGT1Uxy7h34= X-Google-Smtp-Source: ABdhPJxirAIkS11MEy/ZRmr8PueFxeSLCrcdk6d0muLV8TyhsEA0rMKdNOIrKwWQgtoeMNgSCGx/dg== X-Received: by 2002:a05:6000:1689:b0:1f0:436b:e002 with SMTP id y9-20020a056000168900b001f0436be002mr2316719wrd.58.1646237463108; Wed, 02 Mar 2022 08:11:03 -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 bh15-20020a05600c3d0f00b003816824aa54sm8564457wmb.27.2022.03.02.08.11.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Mar 2022 08:11:02 -0800 (PST) Message-ID: <50f75fc6-df4b-8408-4843-7d3363ed6f1a@palves.net> Date: Wed, 2 Mar 2022 16:11:01 +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 01/11] change gdb.base/skip.exp to use finish instead of step Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <20220126195053.69559-1-blarsen@redhat.com> <20220126195053.69559-2-blarsen@redhat.com> From: Pedro Alves In-Reply-To: <20220126195053.69559-2-blarsen@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.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, 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: Wed, 02 Mar 2022 16:11:07 -0000 On 2022-01-26 19:50, Bruno Larsen via Gdb-patches wrote: > skip.exp was making use of a fixed amount of step commands to exit > some functions. This caused some problems when testing GDB with clang, > as it doesn't add epilogue information for functions. Since the step > commands weren't testing important features, they were changed to finish > commands. I'm not a fan of _completely_ avoiding stepping out of functions, due to some compilers misbehaving. I mean, if we're going to do this throughout the testsuite, then we should at least have one testcase that is explicitly about stepping out of a function with step, one that exhibits the problem, and we can concentrate the xfails there (and we should press the compiler folks to fix it). I'm not sure we have one. If we do, you should mention it explicitly in the commit log. Afterall, users will be doing this too.