[fetter-devel] mostly Windows/VC++ issues (name mangling, calling conventions and exception handling)

[whahappan+e8 at gmail.com]

Hi,

First, I want to tell that Verrazano is a superb project,
(potentially) enabling a new level of CL/C++ integration; great work,
Rayiner!

(Btw, what license does Vzn come with? I wasn't able to find any
information on this. I think this license uncertainty may hinder Vzn
adoption by some people (e.g. is Vzn GPL or LLGPL, BSD is a
significant matter for both open- and closed source projects))

Second, there are some apparent problems (most are Windows/VC++ specific):

1. Calling conventions for member functions

VC++ by default uses __thiscall calling convention for class member
functions which on x86 platforms does pass 'this' pointer in ECX
register rather as hidden first parameter on stack and is obviously
unsupported by CFFI. Alternate calling convention could be specified,
but that is not always possible.

2. Name mangling

VC++ name mangling scheme is incompatible with GCC's one and is
undocumented (there are ways to demangle a name to a human-readable
form, but again output format is not really specified)

Specifying 'extern "C"' for C++ functions doesn't solve entire problem
since such functions cannot have C++ data types as return values
(compiler allows only POD types here)

3. Exception handling (not MS-specific, applies to GCC)

C++ exceptions, which are integral part of many C++ APIs, must be
handled properly to achieve full CL/C++ interface. As there are no CL
implementations capable of catching C++ exceptions along the FFI to my
knowledge, this must be handled by Verrazano or its runtime.


Below is description of my vision of how these problems could be
solved, but before I would like to see Rayiner's opinion on this,
since, undoubtedly, these problems (at least exception handling) ought
to be considered when Verrazano was conceived; maybe I overlooked
something.

One solution to these problems could be introducing automatically
generated C-compatible wrapper functions for all C++ function calls
and global variable access. (In fact, the assumption that C++
functions could be used transparently through C-oriented FFIs and that
C++ ABI for given compiler is compatible with its C equivalent is not
really true, at least on Windows platforms, so going through C layer
may be the only correct solution)

This generated wrapper function should do the following:

1. Perform actual C++ function/method/operator/etc. call
2. Pass return value through additional pointer argument
3. Provide C++ exception handler with catch(...) to enable correct
stack unwinding
4. Provide C++ exception run-time type information (this is impossible
in standard C++, but for two major special cases, GCC and VC++, this
could be done; I have working code for VC++)

There should be an additional CL wrapper for return value handling and
exception translation.

There's an example of C++ wrapper function:

extern "C" vzn_status __declspec(dllexport) wrapper_<gcc mangled
name>(Type *self,
 <function arguments>, Return_type *retval, Vzn_cxx_exception_info
*exception_info)
{
 try {
   *retval = self->method(<function arguments>)
   return vzn_success;
 }
 catch (...) {
   some_magic(exception_info); // extracts exception information from
compiler-generated
                                              // data in unportable way
   return vzn_exception;
 }
}

In principle, exception handling could be performed entirely on CL
side in CFFI-portable way (at least on win32), but correct C++  stack
unwinding seems to be next to impossible (this is completely
undocumented matter in case of VC++)


Next, there's problem about C++ name translation: when there are
spaces, colons or commas in C++ name (which is often the case with
templates and namespaces), it doesn't work. I made a patch
(vzn:translate-name) that forces C++ names into |...| form when there
are symbols that clash with CL readtable (I could provide the patch,
however it's very simple, just few lines)

Also, there's another problem I found (cvs snapshot from 05012005):
Vzn does not generate CFFI descriptions for template instantiations
(which are more or less equivalent to non-templates for practical
matters). E.g. if we have a function returning std::basic_string<...>,
Vzn doesn't generate cffi:defcstruct for it; as a result CFFI
complains about unknown type. What would the best place to look into
this (I'm not really understand the whole codebase, so I'm asking
first)?

Regards,
Vladimir