From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28149 invoked by alias); 14 Apr 2014 22:47:02 -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 28120 invoked by uid 89); 14 Apr 2014 22:47:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 14 Apr 2014 22:46:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 013521160E7; Mon, 14 Apr 2014 18:46:56 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g3gVb-QizJnV; Mon, 14 Apr 2014 18:46:56 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C26FB1160E3; Mon, 14 Apr 2014 18:46:56 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 64E77E02C0; Mon, 14 Apr 2014 15:47:02 -0700 (PDT) Date: Mon, 14 Apr 2014 22:47:00 -0000 From: Joel Brobecker To: David Blaikie Cc: Eric Christopher , gdb-patches Subject: Re: [patch] [gdb/testsuite] include a use of the definition of a type to cause clang to emit debug info Message-ID: <20140414224702.GT4250@adacore.com> References: <20140414131050.GR4250@adacore.com> <20140414181623.GS4250@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00284.txt.bz2 > Minor (but important) correction: this isn't introducing a typedef, > it's introducing a variable. OK - sorry for the confusion - I went too fast and it changes the perspective a little. > 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. I don't remember if this was ever discussed, but it should be compiler-neutral, IMO, even if we do have a practical bias towards GCC. The intent is to test that, with the compiler you have, GDB is able to debug your code as expected. > But it'd probably be nice to separate out those things a little We try to do it, sometimes. That's why we have gdb.dwarf2. Ideally, for every testcase, we'd create one using assembly sources to control exactly the code/debug-info produce, and one where we compile some source which, at some point, resulted in the assembly we used in our first testcase. That way, we test both the handling of that particular output, as well as the user-level handling of whatever gets generated by your compiler. But it is a lot of work, and sadly, usually only one of the two options is elected when new testcases are added. Just a practical matter. > 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. My position, in this situation, is that your change is actually not completely neutral: Even if this was not the initial intention when the test was written, as it is now, it allows us to verify that the compiler produces the full debugging information for an enum type even in the case where the type is only referenced through a pointer. By adding a global variable, we lose that part, potentially allowing GCC to regress (from a GDB user's perspective). If the type was opaque, I would have had no objection. But in this case, I try to put myself in the shoes of a user debugging that code, and it would seem reasonable to be able to dereference "e". -- Joel