From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18211 invoked by alias); 14 Apr 2014 18:35:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18155 invoked by uid 89); 14 Apr 2014 18:35:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f46.google.com Received: from mail-qa0-f46.google.com (HELO mail-qa0-f46.google.com) (209.85.216.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 14 Apr 2014 18:35:21 +0000 Received: by mail-qa0-f46.google.com with SMTP id i13so8405079qae.33 for ; Mon, 14 Apr 2014 11:35:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.114.209 with SMTP id f17mr21721332qaq.40.1397500519591; Mon, 14 Apr 2014 11:35:19 -0700 (PDT) Received: by 10.140.30.74 with HTTP; Mon, 14 Apr 2014 11:35:19 -0700 (PDT) In-Reply-To: <20140414181623.GS4250@adacore.com> References: <20140414131050.GR4250@adacore.com> <20140414181623.GS4250@adacore.com> Date: Mon, 14 Apr 2014 18:35:00 -0000 Message-ID: Subject: Re: [patch] [gdb/testsuite] include a use of the definition of a type to cause clang to emit debug info From: David Blaikie To: Joel Brobecker Cc: Eric Christopher , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00279.txt.bz2 On Mon, Apr 14, 2014 at 11:16 AM, Joel Brobecker wrote: >> > The gdb11479.exp is obvious and can be pushed. The change to gdb11479.c, >> > on the other hand, changes the test, and I don't think we want that, >> > because I disagree with the outcome of Clang's optimization here. >> > If Clang doesn't want to fix the problem, best to just xfail the test >> > with Clang, and write a new one that provides the type definition as >> > Clang wants it. >> >> Could you describe your objection here? In particular, as it relates >> to Dave's analysis of a similar gcc optimization. (Also a few people >> have been interested in implementing this same behavior in gcc). > > The fact is, at the moment, that GCC generates the necessary debugging > information, without the need to create a typedef. Minor (but important) correction: this isn't introducing a typedef, it's introducing a variable. > If it stops working > thanks to a GCC "optimization", I would like to know about it (personally). This comes into a discussion about whether the GDB test suite is a test suite for GCC (or Clang) or for GDB. I'm by no means in a position to make a claim as to which of these things it is, though it's clear that GCC and Clang use this suite to validate their behavior relative to GDB. But it'd probably be nice to separate out those things a little - this test case isn't intended to test that GCC behavior. I believe/assume this test case could still test the GDB behavior that it was committed to validate without tickling the difference between GCC and Clang. I've tried to be consistent to this principle with the patches I'm providing - if there's a difference in Clang and GCC behavior that's not necessary for a test case to test GDB and the test can be adjusted to be neutral to that difference, I've tried to change the tests in that direction. In cases where a GCC or Clang output makes it impossible to test a GDB feature (eg: "compiler X produces this quirky output that GDB should handle nicely") I've either XFAILed the test if the difference is a bug in the other compiler or adjusted the test to mark as UNSUPPORTED when run under the other compiler ("hey, we can't produce that quirky output on this compiler so in this configuration we can't test that GDB can cope with it") It's a bit fuzzy - I've XFAILed some thing that are bugs in one compiler or the other even when the test case might be able to be made agnostic to the difference because it took less time than refactoring the test, and hey "it's a bug anyway". > In this particular case, the type is used locally, albeit as a pointer, > and it would seem unfriendly to me that the user not be able to either > print the pointed object's size, or any of the enum's element, just > because it is only used via a pointer. GCC has similar optimizations that might surprise you: struct foo { virtual ~foo(); }; foo f; // GCC and Clang only emits a declaration of 'foo' here If you make that dtor non-virtual, you'll get a definition. The optimizations here are founded on the assumption that the whole program will be built with debug info (in the virtual example above, we know the type has a key function that must be defined /somewhere/ so just emit the full definition of the type when we emit the definition of that key function - in the case of Clang's optimization the assumption is that /some/ translation unit in the program will dereference the pointer, and at that point we'll emit the definition of the type). These assumptions are worth a substantial amount (easily 10s of percent of unlinked debug info size - and only less in the linked case if you use type units) and have clear value to many users. > I also seems strange to me > that an unused typedef is enough to trigger full debug info generation, > while a variable indirectly referencing a type is not. (as mentioned, it's actually a global variable of the type, rather than a typedef) The way Clang works is that any action that would require the full definition of the type that was already being emitted, causes the full definition to be emitted, if that makes sense (I can provide examples/more words - it is a bit hard to articulate clearly). > That's why I suggested that we keep the current testcase as is, > with an xfail with clang, and create a new one if we want to, that > tests the behavior with the proposed work around. > > That's only my opinion, however; it would be fine for the change > to go in if other maintainers disagree with me and approve the change. Fair enough - I think the conversation's useful in any case, to help understand how these different priorities coexist within the project. - David