From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27929 invoked by alias); 1 Apr 2009 21:40:29 -0000 Received: (qmail 27915 invoked by uid 22791); 1 Apr 2009 21:40:27 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from ugmailsa.ugent.be (HELO ugmailsa.ugent.be) (157.193.49.116) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Apr 2009 21:40:19 +0000 Received: from localhost (localhost [127.0.0.1]) by ugmailsa.ugent.be (Postfix) with ESMTP id 1D9E0306B8C for ; Wed, 1 Apr 2009 23:40:16 +0200 (CEST) Received: from ugmailsa.ugent.be ([127.0.0.1]) by localhost (ugmailsa.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OiOhBUsy9Qq for ; Wed, 1 Apr 2009 23:40:15 +0200 (CEST) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by ugmailsa.ugent.be (Postfix) with ESMTP id DE04E3068AF for ; Wed, 1 Apr 2009 23:40:15 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKF700mdwc4w/2dsb2JhbADPVYN9Bg Received: from mail.elis.ugent.be ([157.193.206.48]) by relayrec.ugent.be with ESMTP; 01 Apr 2009 23:40:15 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.elis.UGent.be (Postfix) with ESMTP id 300992BAB7C for ; Wed, 1 Apr 2009 23:40:09 +0200 (CEST) Received: from [127.0.0.1] (ssh2.elis.UGent.be [157.193.206.127]) by mail.elis.UGent.be (Postfix) with ESMTP id 1EC7F2BAB6E for ; Wed, 1 Apr 2009 23:40:09 +0200 (CEST) Message-Id: From: Jonas Maebe To: gdb@sourceware.org In-Reply-To: <20090401201952.GA22834@caradoc.them.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Skipping over trampolines/stubs Date: Wed, 01 Apr 2009 21:40:00 -0000 References: <4B835C7C-B28E-4552-87E0-25D803741FA3@elis.ugent.be> <20090401191446.GA18926@caradoc.them.org> <83CD35E6-FDD6-4A4B-A5E2-14AC30D609DA@elis.ugent.be> <20090401201952.GA22834@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00016.txt.bz2 On 01 Apr 2009, at 22:19, Daniel Jacobowitz wrote: > On Wed, Apr 01, 2009 at 10:15:33PM +0200, Jonas Maebe wrote: >> Which brings me to the next point: how does one go about >> "allocating" a >> new DW_AT_calling_convention value in the DW_CC_lo_user .. >> DW_CC_hi_user >> range? At first sight, there is only one such value currently in >> public >> use (DW_CC_GNU_renesas_sh). Can I just take 0x41 for >> DW_CC_BORLAND_fastcall_i386? And should I then submit this constant >> for >> inclusion in binutils first? > > I don't know - might want to raise this on the DWARF discussion list > (see dwarfstd.org). In case anyone else would ever wonder about this, below is the first answer I received (since the archives for the dwarf-discuss list are limited to subscribers). It appears that it's entirely up to binutils/ gdb maintainers in this case. Jonas From: roland at redhat.com Subject: Re: [Dwarf-Discuss] Reserving a new DW_AT_calling_convention value Date: Wed 1 Apr 2009 23:26:58 GMT+02:00 To: jonas.maebe@elis.ugent.be Cc: dwarf-discuss@lists.dwarfstd.org > I would like to use a new DW_AT_calling_convention attribute value in > the range DW_CC_lo_user .. DW_CC_hi_user. As far as I can tell, the > only one currently in (public) use is DW_CC_GNU_renesas_sh (= 0x40). > My question is: how does one go about reserving/obtaining such a > number? Do you just take the next one that appears to be available and > submit patches using this value to binutils (for elf/dwarf.h) and gdb? > (and possibly dwarflib, and maybe others) In the lo_user..hi_user range, it is up to each "vendor" to decide the conventions for using that range. The different implementors ("vendors") try to stay aware of each other's uses, but "vendor-specific extensions" means exactly that there is not any shared formal management of that space. The DWARF committee decides on the common uses in the