Re: [RFC] Supporting alternative ABIs

[Michael Elizabeth Chastain <mec@shout.net>]

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