From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 443AD3857033 for ; Mon, 12 Sep 2022 09:34:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 443AD3857033 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-209--DEVO1UWPWKRmsm1ovZWOw-1; Mon, 12 Sep 2022 05:34:35 -0400 X-MC-Unique: -DEVO1UWPWKRmsm1ovZWOw-1 Received: by mail-wr1-f70.google.com with SMTP id u27-20020adfa19b000000b0022863c08ac4so1422238wru.11 for ; Mon, 12 Sep 2022 02:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date; bh=5o4WwKc7q91diQuxjA50xQ4Zul50BYTNws/gWMpWUW0=; b=msz50IuA/anr5zi/7wykfUr7SNtRNv+eFB2YJYVgCHLVDBTPleUJHeAX5AlgnowFfP Rx0IlaN0j+sYRMjNL93Dq/cBBQRGDbumqbVUkN+b6Et4DkyBJnP3rVMr4gtppTI7LmcW dntPK6ZjNHRkurxtBT04HbmrK8X6ztfa02rRcEQsJLnHWzkBHyjvjTIggS3ln4J3aRMw sb8lfgK8G7eCcm8SyCwGRMchq5vEYjq/5kWa74rB5O8L1JKI4aaXldXFi1vpKRZfiD5w KC+UozECV/C+QR1MbmFMiQyAv/w6dcCdhDaZ5Is7HW4vJYZ2Yv58k+d+YWzKf9Vm2aIn 8WOg== X-Gm-Message-State: ACgBeo02zuia3EWCCTdJh2Sn8Jd5BaT3J2uFyfakZc3cvqf2ue9rQKh8 M0KiXsi/mnfS/5s/yaI9WnevhJYVeL9U+tCp+d8lYgaNcEfjGHYhJR6dwpJNxAWUQMjOvdhZxtp YyIKb6yTB+JBj0/vFj75VTg== X-Received: by 2002:a5d:59a7:0:b0:22a:47e3:a1b with SMTP id p7-20020a5d59a7000000b0022a47e30a1bmr5529691wrr.319.1662975274715; Mon, 12 Sep 2022 02:34:34 -0700 (PDT) X-Google-Smtp-Source: AA6agR7LCFcCOHs0y9rpzp/qi97EgKl8XWuorMvhQiQHyPsWb548GmwYHjgQJ4aRBrvdopu2JEfYSA== X-Received: by 2002:a5d:59a7:0:b0:22a:47e3:a1b with SMTP id p7-20020a5d59a7000000b0022a47e30a1bmr5529686wrr.319.1662975274490; Mon, 12 Sep 2022 02:34:34 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id f12-20020a05600c154c00b003a5f3f5883dsm10093796wmg.17.2022.09.12.02.34.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 02:34:34 -0700 (PDT) From: Andrew Burgess To: Bruno Larsen , gdb-patches@sourceware.org Subject: Re: [PATCH v4 05/15] update gdb.base/info-program.exp to not fail with clang In-Reply-To: <20220720194441.168906-7-blarsen@redhat.com> References: <20220720194441.168906-1-blarsen@redhat.com> <20220720194441.168906-7-blarsen@redhat.com> Date: Mon, 12 Sep 2022 10:34:32 +0100 Message-ID: <87sfkxkkbb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 12 Sep 2022 09:34:38 -0000 Bruno Larsen via Gdb-patches writes: > The updated test specifically mentions that it doesn't care where the I think this sentence makes more sense without 'updated'. > program stops, however it was still testing for something. With this s/something/a specific location/ ? I think it might be worth adding a sentence before the 'With this...'. The clang compiler emits different line information for function epilogue, and so GDB reports the stop at a different location. Then finish with: 'With this patch the test works even with clang.' > correction, the test works even if the compiler doesn't emit line table > entries for the function epilogue. > --- > gdb/testsuite/gdb.base/info-program.exp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/info-program.exp b/gdb/testsuite/gdb.base/info-program.exp > index facc13efa2f..f652cfbf426 100644 > --- a/gdb/testsuite/gdb.base/info-program.exp > +++ b/gdb/testsuite/gdb.base/info-program.exp > @@ -28,7 +28,7 @@ gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped at breakpoint $ > > # We don't really care where this step lands, so long as it gets > # the inferior pushed off the breakpoint it's currently on... > -gdb_test "next" "$decimal\t.*" "step before info program" > +gdb_test "next" ".*" "step before info program" I think I'd be tempted to rewrite this comment. Currently we say that we don't care where we stop, just so long as we stop somewhere else. The test used to ensure that we did indeed stop somewhere else. The problem is with clang, that somewhere else might be different. But, but using '.*' as a pattern, we're not actually checking that we've moved at all. However, I don't think that actually matters, based on the next thing we do, I think this comment would do: # We don't really care where this `next` lands, so long as GDB reports # that the inferior stopped due to a step in the subsequent test. With these changes I think this patch can be merged. Thanks, Andrew > > gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped after being stepped\.\r\nType \"info stack\" or \"info registers\" for more information\." \ > "info program after next" > -- > 2.31.1