From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4200 invoked by alias); 23 Nov 2004 22:24:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3360 invoked from network); 23 Nov 2004 22:23:56 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sourceware.org with SMTP; 23 Nov 2004 22:23:56 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by palrel12.hp.com (Postfix) with ESMTP id DCADF433034; Tue, 23 Nov 2004 14:23:55 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id iANMNssA023555; Tue, 23 Nov 2004 14:23:54 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.13.1/8.13.1/Debian-16) with ESMTP id iANMNrrA006042; Tue, 23 Nov 2004 14:23:53 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.13.1/8.13.1/Submit) id iANMNrVT006039; Tue, 23 Nov 2004 14:23:53 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16803.47225.505991.886555@napali.hpl.hp.com> Date: Tue, 23 Nov 2004 22:29:00 -0000 To: gcc@gcc.gnu.org, binutils@sources.redhat.com Subject: GNU DWARF augmentation authority Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2004-11/txt/msg00854.txt.bz2 Who (or what) is the authority that can bless extensions to the format of the CIE augmentation string which appear in the .eh_frame sections? I'm asking since I'm working on two extensions: one to enable the marking of special frames (such as signal-frames, see [1]) and one to better support dynamic code generators. It would be nice if these extensions could be blessed "officially", so that we don't run the risk of ending up with conflicting extensions. Just to be clear, in both cases the extensions are backwards-compatible in the sense that an unwinder who doesn't know about the extensions can simply ignore them and it won't work any worse than without the extension (and of course, for extension-aware unwinders can work better). Thanks, --david [1] http://uwsg.iu.edu/hypermail/linux/kernel/0411.2/1370.html