This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Support for multiple calling conventions


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)
+  /* 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

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'

Which one of them is preferrable?


(*) 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]