From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17051 invoked by alias); 11 Apr 2008 10:52:55 -0000 Received: (qmail 16650 invoked by uid 22791); 11 Apr 2008 10:52:51 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 11 Apr 2008 10:52:34 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 79F776D4312; Fri, 11 Apr 2008 12:52:31 +0200 (CEST) Date: Fri, 11 Apr 2008 12:56:00 -0000 From: Corinna Vinschen To: gdb@sourceware.org Subject: Support for multiple calling conventions Message-ID: <20080411105231.GG23852@calimero.vinschen.de> Reply-To: gdb@sourceware.org Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) 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: 2008-04/txt/msg00092.txt.bz2 Hi, resurrecting an old problem from 2002 or 2003: On the sh processor, there exist two different calling conventions (CC) for functions, the "gcc" and the "renesas" CCs. GCC uses the gcc CC by default, but can switch to the renesas CC by using the __attribute__((renesas)) function attribute To notify the debugger about the different CCs, GCC adds the Dwarf-2 attribute DW_AT_calling_convention to the DW_TAG_subprogram die, as soon as the function uses the renesas CC, setting the attribute to the value DW_CC_GNU_renesas_sh (0x40) (*). While this is sh specific right now, there would be certainly other cases in which the DW_AT_calling_convention could be used in a generic way, as long as the compiler emits this information. Therefore I'm trying to find a generic solution. So far, GDB has no support for the DW_AT_calling_convention function attribute, except for a special fortran case. After some mulling over this, I found that the CC would best fit into the functions's type structure. dwarf2read.c:read_subroutine_type creates a single type struct per function, along these lines: --- dwarf2read.c 17 Mar 2008 15:16:26 -0000 1.22 +++ dwarf2read.c 11 Apr 2008 10:36:42 -0000 @@ -4887,6 +4887,12 @@ read_subroutine_type (struct die_info *d || cu->language == language_pascal) TYPE_FLAGS (ftype) |= TYPE_FLAG_PROTOTYPED; + /* Store the calling convention in the type if it's available in + the subroutine die. Otherwise set the calling convention to + the default value DW_CC_normal. */ + attr = dwarf2_attr (die, DW_AT_calling_convention, cu); + ftype->calling_convention = attr ? DW_UNSND (attr) : DW_CC_normal; + if (die->child != NULL) { struct die_info *child_die; This allows the push_dummy_call functions to retrieve the CC from the function type they get as second parameter. So far so good. But the problem is this: The CC is also needed in the return_value functions to recognize different struct return conventions etc. However, the return_value functions only get the value type as parameter, not the function type. And worse: There's no other function specific argument to the return_value functions which means, there's no way to retrieve the CC at all within these functions. So I'm wondering how to solve that problem. I can see three different approaches: - The return_value functions get the function type as argument, not the value type. They have to retrieve the value type from the function type themselves. - The return_value functions get an addition function type argument. - The return_value functions get an addition `unsigned calling_convention' argument. Which one of them is preferrable? Corinna (*) Additionally the user can enforce the renesas CC using a command line switch. This allows to debug renesas ABI functions created with compilers not aware of the DW_AT_calling_convention. -- Corinna Vinschen Cygwin Project Co-Leader Red Hat