From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 7ACAE38708CD for ; Fri, 26 Jun 2020 09:37:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7ACAE38708CD Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-402-kLInpKHCP_CAxWtEYevNbA-1; Fri, 26 Jun 2020 05:37:30 -0400 X-MC-Unique: kLInpKHCP_CAxWtEYevNbA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E50291054F8F; Fri, 26 Jun 2020 09:37:28 +0000 (UTC) Received: from blade.nx (ovpn-114-112.ams2.redhat.com [10.36.114.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6CED97933E; Fri, 26 Jun 2020 09:37:28 +0000 (UTC) Received: by blade.nx (Postfix, from userid 1000) id ABCD6816CCA9; Fri, 26 Jun 2020 10:37:27 +0100 (BST) Date: Fri, 26 Jun 2020 10:37:27 +0100 From: Gary Benson To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [committed][gdb/testsuite] Update psym-external-decl.exp for gcc-10/clang Message-ID: <20200626093727.GA8682@blade.nx> References: <20200502075127.GA21196@delia> <20200617122432.GA28940@blade.nx> <20200618161044.GA1032@blade.nx> <21d9fcc8-62c4-d1a5-f085-0c7f26783255@suse.de> <20200619140041.GB31823@blade.nx> <6dd30362-e9dd-6bc9-bf40-8b846b926e5a@suse.de> MIME-Version: 1.0 In-Reply-To: <6dd30362-e9dd-6bc9-bf40-8b846b926e5a@suse.de> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 26 Jun 2020 09:37:33 -0000 Tom de Vries wrote: > On 6/19/20 4:00 PM, Gary Benson wrote: > > Tom de Vries wrote: > > > On 6/18/20 6:10 PM, Gary Benson wrote: > > > > Tom de Vries wrote: > > > > > On 6/17/20 2:24 PM, Gary Benson wrote: > > > > > > Tom, I'd like this testcase to not fail silently. Is the > > > > > > functionality under test something that isn't ever > > > > > > expected to work with clang, or is this a test that should > > > > > > pass with clang (but it currently doesn't, for whatever > > > > > > reason)? > > > > > > > > > > I'm not sure. The test can pass with clang, provided it > > > > > generates the required debug info. It currently doesn't. > > > > > Why that is the case, I have no idea. > > > > > > > > I think that means the test should work but it doesn't. Would > > > > you object if I push a patch removing the test-skipping logic? > > > > It will mean an extra FAIL when tested using clang > > > > > > I don't think having a fail for a compiler bug/missing-feature > > > is a good idea. > > > > > > If this is due to a bug/missing-feature in clang, then we need to: > > > - xfail the test, > > > - file the PR in clang, and > > > - reference the PR at the xfail. > > > > Is this a bug/missing feature in clang though? > > How sure are you GDB isn't at fault? > > Clang emits less debug info than GCC. Whether that's a bug, a > missing feature or an explicit unsupported feature in clang, I > don't known. > > I known that gdb isn't at fault. It can't do anything without the > missing debug info. The test was specifically written to use that > debug info. I'm not really sure what's the right thing to do here. On the one hand, my current task is ensuring GDB can debug clang-compiled with clang as well as it can debug GCC-compiled code. From that perspective the skip-if-clang logic in this test is hiding a failure I need to investigate. On the other hand, I'm an engineer working on GDB, and from that perspective I want to be able to run the GDB testsuite and see 100% pass, on whatever setup I test it on. And yes, I know it doesn't... but it *should*. Is there a way to pass a "don't skip clang failures" flag to the testcases, such that people running the testsuite normally would see tests like these return UNSUPPORTED, but I could run the testsuite with the flag so it'd not skip but FAIL wherever the problem is? Thanks, Gary -- Gary Benson - he / him / his Principal Software Engineer, Red Hat