From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by sourceware.org (Postfix) with ESMTPS id 87254389043A for ; Mon, 29 Jun 2020 12:32:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87254389043A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f68.google.com with SMTP id r12so16310731wrj.13 for ; Mon, 29 Jun 2020 05:32:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n82abwiIGOTfhTCpxBP38h2PMPP4gzUbXye22lLlvHI=; b=ROfgdMhvEVsx2XRUB7FgzlEdEoV/puvYpEj58R5nPOAmKRH4eXbzTAEIVFkLgSYSdT bQ1WpECArsq8Y9lGY2VwN0sULrDD1Epd+AJtvCAFt3boRMP8cDuMqSXZM62KAZ62hjE7 9hdjQkV+RWZyHFHH6Vx0df5pHCMb9B2R7OgWM0iRyxkzY2b2iqboSc4plBFfrru986OW 1O+rZ0VHECNTtRhqoS1Bfaqn/Pnw0/Qmwsu/ELneBX1k/ru+uZ0CW9vYu3cMZtZ2H8M3 rjzrFi6noNfoh8WRqw7LalnlNbPnzYw+swHiKobJwxH71HysVi7fk9qbU7eSb8LNM7Xz fROw== X-Gm-Message-State: AOAM533KCVl5PaMdwtZeqHCjXoI9PLMuN1ea9Ig5La+xelNJ1/EOcJU5 4zWvPryKuS1gg0GL5fnJop84tRvB6NZcXg== X-Google-Smtp-Source: ABdhPJx+KDKAYcZv0g37OWndHVPn7HdPRq7+u/li5Fwh2Su8/YjMumc4+nk2miYtzYPLhNgofEmgBw== X-Received: by 2002:a5d:4e87:: with SMTP id e7mr17833013wru.12.1593433959366; Mon, 29 Jun 2020 05:32:39 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id v11sm36030508wmb.3.2020.06.29.05.32.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 05:32:38 -0700 (PDT) Subject: Re: [committed][gdb/testsuite] Update psym-external-decl.exp for gcc-10/clang To: Tom de Vries , Gary Benson 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> <20200626093727.GA8682@blade.nx> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 29 Jun 2020 13:32:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: Mon, 29 Jun 2020 12:32:42 -0000 On 6/28/20 11:50 AM, Tom de Vries wrote: > On 6/26/20 11:37 AM, Gary Benson wrote: >> 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? > > I think the following is a good way of dealing with this. > > We introduce a proc in gdb.exp called debug_info_for_decl or some such, > that returns false by default for clang. I think it would be useful to include an intro description to gdb.base/psym-external-decl.exp since it currently doesn't describe what it is testing. Looking at the commit log of the patch that introduced it helps, but one shouldn't have to do that. So the difference between gcc and clang AFAIU is that gcc emits debug info for the extern variable declaration (and with newer GCCs, only if there's a reference to the variable in the CU, otherwise not even so), while seemingly clang would only emit debug info for the variable's definition, which isn't compiled with -g, so we end up with no debug info for the variable. I would suggest filing a bug with clang, to confirm whether this is intentional, or whether they see it as a bug. I would think it is a bug, but I'm not sure. If indeed a bug, we would XFAIL the test. > > Instead of testing for a specific compiler in the test-case, we call > this new proc, and mark the test-case UNSUPPORTED if it returns false. > > Then if you want to see how clang performs if we expect it to have that > feature, you comment out the clang-specific code in the proc. > > Thanks, > - Tom >