Re: [RFC] Supporting alternative ABIs

Re: [RFC] Supporting alternative ABIs

[Michael Elizabeth Chastain]

What a coincidence!   I have been looking at the code which
does this on other platforms.  There is code to handle
alternate function calling conventions in arm-tdep.c, m68hc11-tdep.c,
mips-tdep.c, and sh-tdep.c.

These arches store 1 or 2 bits in the minimal symbol (msym)
which indicate the calling convention.  I'll walk through
arm-tdep.c because it is one of the oldest.

First, there are some hideous macros to set and retrieve bits
in msym->info.  I learned about this stuff because I am planning
to convert these macros into more normal bit accesses.  If you look
past the macros, the point is to set bits and test bits on the
msym.

First, there are gdarch callback hooks, ELF_MAKE_MSYMBOL_SPECIAL
and COFF_MAKE_MSYMBOL_SPECIAL.  When the Elf reader or Coff reader
creates an msym, it calls this gdbarch method.  This calls into
arm_elf_make_msymbol_special or arm_coff_make_msymbol_special.

These functions extract information out of the bfd asymbol
(for elf) or the storage class (for coff) reader.  They store
information about the calling convention in the msym.

Later, there is lots of code in arm-tdep.c which checks this
bit in the msym to decide what to do.  Look at all the calls
to arm_pc_is_thumb (pc).

Jim's proposal is to put the information in main_type
for this platform, rather than putting it in minimal_symbol like
arm, m68hc11, sh, and tdep.

The big drawback I see is that you don't have main_type
information for libraries and unelss the lirbary is compiled with
debug info.  If all you need this information for is
calling functions by hand, this is not bad.  But they are
different calling conventions: do you also need this information
for prologue analysis and frame analysis?  Does 'backtrace'
depend on this information?

Michael C

Re: [RFC] Supporting alternative ABIs

[Andrew Cagney]

> What a coincidence!   I have been looking at the code which
> does this on other platforms.  There is code to handle
> alternate function calling conventions in arm-tdep.c, m68hc11-tdep.c,
> mips-tdep.c, and sh-tdep.c.

In the case of ARM (Arm vs Thumb), sh (sh vs sh64) and MIPS (MIPS vs 
MIPS16) the tdep file has effectively encountered two different 
architecture variants (ISA) folded into a single architecture.  For what 
corinna is looking at, the ABI and not the ISA is being changed.

Roughly speeking there is the relationships:

	ISA N->M ABI

e.g., for MIPS, MIPS16 has only one ABI (two?) while MIPS32 and MIPS64 
to a certain extend share the -o32 -64 -o64 and -n64 ABIs.

The current architecture is flat.  Refecting the original design it 
contains everything.  With everything multi-arch (not yet strictly true 
unfortunatly) a more oo model can probably be developed.  All the 
inferior functioin call stuff moved to a separate object - more like the 
frame code.

Andrew

Re: [RFC] Supporting alternative ABIs

[Andrew Cagney]

> Corinna Vinschen <vinschen@redhat.com> writes:
> 
> 
> - EXTRACT_RETURN_VALUE, STORE_RETURN_VALUE, USE_STRUCT_CONVENTION and
>   gdbarch_push_dummy_code gdbarch methods would be changed to expect
>   the type of the function, not the type of its return value.  They
>   can use TYPE_TARGET_TYPE to get the return value type, but this will
>   also give them access to the `calling_convention' for the function type.

I just looked at infcall.c:find_function_addr.  GDB sometimes needs to 
compute the function's type and address from incomplete information.

Andrew

Re: [RFC] Supporting alternative ABIs

[Andrew Cagney]

> Corinna Vinschen <vinschen@redhat.com> writes:
> 
> 
>> - EXTRACT_RETURN_VALUE, STORE_RETURN_VALUE, USE_STRUCT_CONVENTION and
>>   gdbarch_push_dummy_code gdbarch methods would be changed to expect
>>   the type of the function, not the type of its return value.  They
>>   can use TYPE_TARGET_TYPE to get the return value type, but this will
>>   also give them access to the `calling_convention' for the function type.
>> 
>> - gdbarch_push_dummy_call and EXTRACT_STRUCT_VALUE_ADDRESS would
>>   receive the function's type as an additional argument, to give them
>>   access to the function's calling convention information.
>> 
>> - USE_STRUCT_CONVENTION and gdbarch_push_dummy_code would not require
>>   the `gcc_p' and `using_gcc' flags anymore since this information
>>   is now given in the function type node.  Due to the way,
>>   gdbarch_parse_dwarf2_calling_convention evaluates the `calling_convention'
>>   value, all inferior call-related gdbarch methods could simply trust its
>>   value.
> 
> 
> I was working on the (32-bit) SPARC target today, and wished I had the
> function type available, so I'm positive this would be a good move.

... so seconded.

Going through them:

USE_STRUCT_CONVENTION:
I'd rename the existing USE_STRUCT_CONVENTION to 
DEPRECATED_USE_STRUCT_CONVENTION and then introduce new arch method 
gdbarch_use_struct_convention (gdbarch, struct type *func) that defaults 
to the old.

push_dummy_call:
Similar.  The struct_return parameter is now very redundant (the 
assertions "struct_return == new USE_STRUCT_CONVENTION (new function 
parameter)", and "(struct_return != 0) == (STRUCT_ADDR != 0)" should hold).

EXTRACT_STRUCT_VALUE_ADDRESS:
Is this one needed?  Instead always use EXTRACT_RETURN_VALUE to obtain 
the return value.  Renaming this to DEPRECATED_STRUCT_VALUE_ADDRESS_V2.

STORE_RETURN_VALUE:
Rename the existing to deprecated_store_return_value_v2?  Anyway, 
looking at set_return_value(), I think the replacement's default 
implementation should incorporate both of:
>   if (code == TYPE_CODE_STRUCT
>       || code == TYPE_CODE_UNION)       /* FIXME, implement struct return.  */
>     error ("GDB does not support specifying a struct or union return value.");
> 
>   STORE_RETURN_VALUE (type, current_regcache, VALUE_CONTENTS (val));
some ABI's allow struct return, some don't.  Generic code shouldn't be 
making the decision.

EXTRACT_RETURN_VALUE:
Rename the existing to deprecated_extract_return_value_v2?  Looking at 
value_being_returned, and given the comment above on 
EXTRACT_STRUCT_VALUE_ADDRESS, I think the default method should contain 
much of the existing value_being_returned function.

Andrew

Re: [RFC] Supporting alternative ABIs

[Mark Kettenis]

Corinna Vinschen <vinschen@redhat.com> writes:

> - EXTRACT_RETURN_VALUE, STORE_RETURN_VALUE, USE_STRUCT_CONVENTION and
>   gdbarch_push_dummy_code gdbarch methods would be changed to expect
>   the type of the function, not the type of its return value.  They
>   can use TYPE_TARGET_TYPE to get the return value type, but this will
>   also give them access to the `calling_convention' for the function type.
> 
> - gdbarch_push_dummy_call and EXTRACT_STRUCT_VALUE_ADDRESS would
>   receive the function's type as an additional argument, to give them
>   access to the function's calling convention information.
> 
> - USE_STRUCT_CONVENTION and gdbarch_push_dummy_code would not require
>   the `gcc_p' and `using_gcc' flags anymore since this information
>   is now given in the function type node.  Due to the way,
>   gdbarch_parse_dwarf2_calling_convention evaluates the `calling_convention'
>   value, all inferior call-related gdbarch methods could simply trust its
>   value.

I was working on the (32-bit) SPARC target today, and wished I had the
function type available, so I'm positive this would be a good move.

Mark

Re: [RFC] Supporting alternative ABIs

[Daniel Jacobowitz]

On Fri, Aug 22, 2003 at 10:40:54AM +0200, Corinna Vinschen wrote:
> Hi,
> 
> we're working on GDB support for a platform that supports two
> different calling conventions; the user can choose which to use on a
> per-function basis.  Obviously, calling a function from GDB should
> work, no matter which convention the function uses.  We'd like folks'
> thoughts on how this information should be carried through, from the
> compiler, which actually has the information, to GDB's inferior
> function call code, which needs it.  Since this problem might arise
> more often in future, we are looking forward to a generic solution.
> Thanks to Jim Blandy, who wrote the first draft of this document after
> a long discussion.

This sounds entirely reasonable to me.  Let's give it up for Dwarf 2,
folks, for saving us from adding another incomprehensible letter to
stabs!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[RFC] Supporting alternative ABIs

[Corinna Vinschen]

Hi,

we're working on GDB support for a platform that supports two
different calling conventions; the user can choose which to use on a
per-function basis.  Obviously, calling a function from GDB should
work, no matter which convention the function uses.  We'd like folks'
thoughts on how this information should be carried through, from the
compiler, which actually has the information, to GDB's inferior
function call code, which needs it.  Since this problem might arise
more often in future, we are looking forward to a generic solution.
Thanks to Jim Blandy, who wrote the first draft of this document after
a long discussion.


The problem: 

The platform has a "native" compiler which uses a calling convention
different from the calling convention used by gcc.  Both ABIs are
valid concurrently and it should be possible to create functions
with gcc, which use the other ABI and to call these functions from
other functions using the gcc ABI and vice versa.

To allow this in gcc per function, you declare a function with an
appropriate attribute:

    int __attribute__ ((use_alternate_abi))
    foo (int x, double y)
    {
      ...;  
    }

This function will expect to be called using the chip's alternative ABI.
Note that this attribute actually applies to the *type* of the
function, as well.  Suppose `pf' is a pointer to a function; in order
for the compiler to generate the right code for:

	(*pf) (1, 2.0)

it needs to know which calling convention the function '*pf' uses.  To
look at it another way, if I declare two functions like this:

    double
    bar (int x, double y) { return x + 2 * y; }

    double __attribute__ ((use_alternate_abi))
    baz (int x, double y) { return x + 2 * y; }

Then '&bar' and '&baz' must be incompatible function types; if we
don't know which one 'pf' is pointing to, we can't generate code to
call through it.  We write the types of '&bar' and '&baz' as follows:

    double (                                    *) (int, double)
    double (__attribute__ ((use_alternate_abi)) *) (int, double)

So, in the general case, GDB needs to be able to successfully call
such functions.  If *pf is &baz, then GDB should work like this:

    (gdb) print (*pf) (1, 2.0)
    $42 = 5.0
    (gdb)

Since functions are immediately promoted to function pointers when
they appear as the operand of almost anything in a C expression,
supporting the case above will automatically support the more
straightforward uses, like:

    (gdb) print baz (1, 2.0)
    $43 = 5.0
    (gdb)


The proposal:

There needs to be a way for the compiler to indicate to the debugger
which functions use the alternative calling convention.  This platform
uses Dwarf 2 as its normal debugging format; it's straightforward to
extend Dwarf 2 to carry this information.  The Dwarf 2 attribute
DW_AT_calling_convention would seem to be appropriate here.  The spec
only describes its use for actual DW_TAG_subprogram nodes (for
functions themselves) not DW_TAG_subroutine_type nodes (for subroutine
types) but it seems like a reasonable extension.  We can specify new
DW_CC_ values, in the range reserved for user extensions, in the
chip's ABI.

GDB needs to read this information, store it in its symbol tables, and
use it in call_function_by_hand.  It's not clear to us how best to do
this, but here is our straw-man proposal.

- Add the following member to 'struct main_type':

      /* For TYPE_CODE_FUNC, target-specific information about how to
	 call this function.  This is zero if the function uses the
	 platform's standard calling convention.  */
      int calling_convention;

- The dwarf2read.c function responsible for reading function types,
  read_subroutine_type, would check for a DW_AT_calling_convention
  attribute on the DW_TAG_subroutine_type die; if present, it would
  pass the attribute's value, an integer, to a new gdbarch method,
  gdbarch_parse_dwarf2_calling_convention.

  Actually, gdbarch_parse_dwarf2_calling_convention would have three
  arguments: attribute_present, calling_convention, and gcc_compiled.
  `attribute_present' is a flag, indicating if DW_AT_calling_convention
  is present in this node, `calling_convention' contains the actual
  value, if any, and `gcc_compiled' is a flag indicating if the function
  has been build using gcc or not.

  We'd call gdbarch_parse_dwarf2_calling_convention for every subroutine
  type node.  The method would return another int, to be stored in the
  subroutine type's `calling_convention'.

- EXTRACT_RETURN_VALUE, STORE_RETURN_VALUE, USE_STRUCT_CONVENTION and
  gdbarch_push_dummy_code gdbarch methods would be changed to expect
  the type of the function, not the type of its return value.  They
  can use TYPE_TARGET_TYPE to get the return value type, but this will
  also give them access to the `calling_convention' for the function type.

- gdbarch_push_dummy_call and EXTRACT_STRUCT_VALUE_ADDRESS would
  receive the function's type as an additional argument, to give them
  access to the function's calling convention information.

- USE_STRUCT_CONVENTION and gdbarch_push_dummy_code would not require
  the `gcc_p' and `using_gcc' flags anymore since this information
  is now given in the function type node.  Due to the way,
  gdbarch_parse_dwarf2_calling_convention evaluates the `calling_convention'
  value, all inferior call-related gdbarch methods could simply trust its
  value.

The advantage of this approach is that it leaves the details about how
to interpret the value of the DW_CC_calling_convention attribute, and
how to represent the calling conventions supported for a particular
architecture, in the hands of target-specific code.  GDB's core code
simply carries that target-specific information from the debug info
reader to the inferior call code.  And having the gdbarch methods that
support inferior calls take the function type, instead of the return
value type, seems natural.

The disadvantage of this is that changing all the gdbarch methods
mentioned above would be a lot of work --- although not that difficult.


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.