Support for multiple calling conventions

Support for multiple calling conventions

[Corinna Vinschen]

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

Re: Support for multiple calling conventions

[Daniel Jacobowitz]

On Fri, Apr 11, 2008 at 12:52:31PM +0200, Corinna Vinschen wrote:
> - 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.

IMO adding the function type is best.  It's more extensible than
adding a calling convention argument which most platforms won't need,
and it changes the signature so that no one will get confused which
type is passed.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support for multiple calling conventions

[Corinna Vinschen]

On Apr 11 08:19, Daniel Jacobowitz wrote:
> On Fri, Apr 11, 2008 at 12:52:31PM +0200, Corinna Vinschen wrote:
> > - 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.
> 
> IMO adding the function type is best.  It's more extensible than
> adding a calling convention argument which most platforms won't need,
> and it changes the signature so that no one will get confused which
> type is passed.

Thanks.  I'll implement it this way next week.  It's just a pity that
so much code has to be touched for such a rather tiny addition...


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: Support for multiple calling conventions

[Daniel Jacobowitz]

On Fri, Apr 11, 2008 at 04:31:29PM +0200, Corinna Vinschen wrote:
> Thanks.  I'll implement it this way next week.  It's just a pity that
> so much code has to be touched for such a rather tiny addition...

Yeah.  If you can think of another way to do it...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support for multiple calling conventions

[Corinna Vinschen]

On Apr 11 10:46, Daniel Jacobowitz wrote:
> On Fri, Apr 11, 2008 at 04:31:29PM +0200, Corinna Vinschen wrote:
> > Thanks.  I'll implement it this way next week.  It's just a pity that
> > so much code has to be touched for such a rather tiny addition...
> 
> Yeah.  If you can think of another way to do it...

That's exactly the problem.  I don't see any other way than to change
the return_value arguments.  I was surprised myself when I found that
I don't have a chance to retrieve anything about the calling function
in {$ARCH}_return_value.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat