This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
- From: Michael Eager <eager at eagercon dot com>
- To: Cary Coutant <ccoutant at google dot com>, Jeff Law <law at redhat dot com>
- Cc: Mark Wielaard <mjw at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Tue, 02 Dec 2014 13:52:47 -0800
- Subject: Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
- Authentication-results: sourceware.org; auth=none
- References: <1416956221-26727-1-git-send-email-mjw at redhat dot com> <547CDE33 dot 4030706 at redhat dot com> <CAHACq4r3uwbiV-nj2M65c_gOL1QOPU2QJ87jry2G+=YyAS6UKg at mail dot gmail dot com> <547CE2C1 dot 6010802 at redhat dot com> <CAHACq4rqUFw8Z==8AsOwHHbRucE=9dQx6=aN3F8n1cK3ufDSQg at mail dot gmail dot com>
On 12/01/14 14:02, Cary Coutant wrote:
[+cc Michael Eager]
Rather than having to lobby to keep it unchanged because we jumped the gun,
can we lobby to get the number assigned in the near future rather than in
the potentially far future? That feels more cooperative to me :-)
Would that make Michael happier?
I'm pretty confident that Michael will say, "don't rely on the value
until the final spec is published." (He's told me exactly that in the
past. I've been guilty of jumping the gun on a couple of DW_LANG codes
and a few DW_AT values.)
But we should let Michael answer for himself...
As Cary said, the values are not fixed until the spec is released.
As Jason said, the values are unlikely to change.
The standards process can be a bit messy at times, particularly
when we realize that something we added to a draft needs to be changed.
We try to avoid making unnecessary changes, naturally. On the other
hand, we don't want something in an internal draft of the DWARF
specification to prevent us from making necessary changes.
We will avoid changing the value of the DW_AT_noreturn or any other
new attribute, if for no reason than it makes additional work for us.
We're also aware that changes may affect work on GCC, GDB, or other
tools, which we would like to avoid.
The most conservative approach is to wait for the DWARF Version
5 spec to be released. While there is no guarantee that attribute
values will not change in the final spec, the risk if this happening
seems small.
Michael, for your reference, here's the start of this thread:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03195.html
and its continuation into December:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00099.html
Michael, are you OK with sharing your target dates for publishing the spec?
We will likely have a public review draft available in April or May
with a 60 period for comments, with final release most likely in July.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077