From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11521 invoked by alias); 21 Sep 2009 21:05:40 -0000 Received: (qmail 11512 invoked by uid 22791); 21 Sep 2009 21:05:40 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 21:05:34 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n8LL5WGg005688 for ; Mon, 21 Sep 2009 14:05:32 -0700 Received: from pzk2 (pzk2.prod.google.com [10.243.19.130]) by zps36.corp.google.com with ESMTP id n8LL4WGT023704 for ; Mon, 21 Sep 2009 14:05:30 -0700 Received: by pzk2 with SMTP id 2so2631647pzk.28 for ; Mon, 21 Sep 2009 14:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.7.2 with SMTP id 2mr6492wfg.104.1253567129719; Mon, 21 Sep 2009 14:05:29 -0700 (PDT) In-Reply-To: <20090921185704.GA3598@bromo.med.uc.edu> References: <4AB58A42.7030801@gmail.com> <20090921185704.GA3598@bromo.med.uc.edu> Date: Mon, 21 Sep 2009 21:05:00 -0000 Message-ID: Subject: Re: GCC 4.5 Status Report (2009-09-19) From: Cary Coutant To: Jack Howarth Cc: Richard Guenther , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00420.txt.bz2 > =A0 Are you saying that current gcc trunk should require -gdwarf-4 > to issue dwarf4 commands? I ask because r151815... > > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html > > causes dwarf4 by default. Is there a consistent policy on this? > Currently in PR41405, there is a proposal for a -gstrict-dwarf > option which I guess should be expanded to cover your patch if > gcc 4.5 will be defaulting to -gdwarf-4 being enabled. That patch actually enables the use of certain DWARF extensions (DW_OP_stack_value and DW_OP_implicit_value) from the DWARF-4 spec while still generating nominal DWARF-2. Since DWARF was designed for extensibility, this isn't a problem for these extensions, as older DWARF readers will simply ignore the location expressions that use the extensions -- which produces the same behavior as DWARF-2 without those extensions. Because the behavior with an older consumer is no worse than the behavior without the extension, it's perfectly reasonable to use these extensions without any gating option. There are a couple of new things in the DWARF-4 spec that are not completely backward compatible with DWARF-2, but none of those are implemented in gcc yet. In fact, my dwarf4 branch still generates nominal DWARF-2 output, while using the extensions from DWARF-4 to allow the separation of type info into separate COMDAT sections. I gate the new behavior on the -gdwarf-4 option, however, since the use of this extension with an older consumer would represent a loss of functionality -- the older consumer would not see any of the type information that was placed in COMDAT sections. Thus, my changes won't be enabled by default, so they won't need to be affected by the -gstrict-dwarf option. I think gcc with -gdwarf-4 can (and should) continue to mark the DWARF output as version 2 until it starts taking advantage of some of the new FORMs (which old consumers will not know how to skip and ignore), the new line number table header format, and the new frame section format. And it shouldn't start taking advantage of those things until gdb support for those features is available. -cary