[DotGNU]Strategy for dealing with C++ virtual functions in a managed binding.

James Michael DuPont mdupont777 at yahoo.com
Tue Dec 3 06:24:32 GMT 2002


--- Adam Treat <manyoso at yahoo.com> wrote:
> On Tuesday 03 December 2002 12:09 am, James Michael DuPont wrote:
> > --- Adam Treat <manyoso at yahoo.com> wrote:
> > > Hello All,
> > >
> > > I would like to pick the brains of the collective intelligence
> and
> > > come up
> > > with a good solid strategy for dealing with C++ virtual functions
> in
> > > a
> > > binding.
> >
> > /me ears pick up something interesting
> >
> > > Our new strategy is then to call the libqt.so directly using
> mangled
> > > method
> > > names in our DllImport attributes.
> > >
> > > This is accomplished by using a
> > > combination of 'nm' and 'cppfilt' during Qt# binding creation.
> >
> > I would like too see this code. /me thinks you can use libiberty
> and
> > the   introspector or gcc_xml for this.
> 
> Oh, we already have a strategy for mangling the names.  A script and 
> nm+cppfilt works nicely.  I can produce this script for you tomorrow
> (it's 
> late ;)  We looked at libiberty for this, but it only provides a
> mechanism 
> for 'demangling' and does not provide a way to 'mangle' given a
> string 
> representing a function prototype.


Here is the code for getting it from the dbxout.c
you will notice that this information is stored in the tree structre.
--------------------------------------------------------------------
	  /* This is the "mangled" name of the method.
	     It encodes the argument types.  */
	  const char *debug_name;

	  /* Skip methods that aren't FUNCTION_DECLs.  (In C++, these
	     include TEMPLATE_DECLs.)  The debugger doesn't know what
	     to do with such entities anyhow.  */
	  if (TREE_CODE (fndecl) != FUNCTION_DECL)
	    continue;

	  debug_name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (fndecl));
--------------------------------------------------------------------

> 
> > >  The
> > > idea is
> > > to use an instance pointer as an invisible first parameter and
> then,
> > > using
> > > the mangled name, call libqt directly.
> >
> > like the gnu libjava
> 
> Oh?  libjava uses this method?  Is this part of gcj then?
Look at libjava/java/net/natPlainSocketImpl.cc
void
java::net::PlainSocketImpl::bind (java::net::InetAddress *host, jint
lport)

this is a clean an interface as you will get.

> 
> > >  Oh, and our binding generator
> > > is also
> > > capable of an easy extension to bind any C++ lib in case anyone
> is
> > > interested
> > > in binding other C++ libraries ;)
> >
> > yes, let us see the basic axioms, we can build this in a standard
> > process.
> >
> > at this point, I would like to know why cannot you use the internal
> > call system? that has a binding generator as well, no?
> 
> The binding generator is pretty flexible and easy to extend to other
> C++ 
> API's.  

> We use a custom C++ header parser written in C# to produce an
> XML 
> file representing the C++ API.  
do you have a spec of the output, I could output this directly from the
gcc-introscptor

> This XML file is then processed
> through our 
> binding generator called 'binge'. 

> What do you mean by 'use the
> internal call 
> system' ?? 
see cvs/pnetlib/doc/native
<title>Internalcall methods for pnetlib</title>
and
cvs/pnet/engine/int_table.c, here is a lookup table of method pointers
(in c) that could be translated somehow into c++.
I still have lots to read. But it looks promising.
---------------------------------------------------------
#ifndef _IL_Decimal_suppressed
IL_METHOD_BEGIN(Decimal_Methods)
	IL_METHOD("Round", "(vSystem.Decimal;i)vSystem.Decimal;",
_IL_Decimal_Round, marshal_vpppi)
	IL_METHOD("Compare", "(vSystem.Decimal;vSystem.Decimal;)i",
_IL_Decimal_Compare, marshal_ippp)
	IL_METHOD("Truncate", "(vSystem.Decimal;)vSystem.Decimal;",
_IL_Decimal_Truncate, marshal_vppp)
---------------------------------------------------------

> I have no idea what you are referring to nor do I
> understand 'has 
> a binding generator as well, no' ... what has a binding generator as
> well?
Sorry for the ambigiguity. I mean the pnet internal calls.
Well there are many files in the pnet that have a scary 
notice "dont touch, autogenerated"
unfortually there is no statement about what program generated them.
I will have to look into this.

> 
> > >  The preferred solution would
> > > be to
> > > somehow override the virtual table to call a managed function
> > > directly and
> > > then somehow forward this to the appropriate C# virtual function.
> >
> > you can grab pointers to virtual function entries,
> > and given an object and a vf pointer call the object.
> >
> > please send me more info,
> > I just might be able to help.
> 
> Awesome!  I don't know what kind of info would be helpful

1. the spec for the xml description of the bindings
2. a single c+ header file with the class definitions that you want to
call.

> ... Our
> ideal 
> solution would allow us to associate a delegate with a C# virtual
> function 
you mean c++ virtual function.

> ... when the virtual function is implemented the binding would pass
> the delegate to a C glue method as a function pointer ... 


> the C glue method could 
> then do some magic with the virtual table in libqt.so and install the
> delegate in place of the existing function pointer. 
You want to overwrite the c++ vtable so that you can call C# from c++,
via the method table?

ok, this will require setting the function pointer of an existing
method. Or involve a second interface.

I would say that i need an exact example,
assuming you could modify the make_thunk function from the gcc,
then you call the c# code.
the makethunk is used on the client side
    fn = make_thunk (fn, delta, vcall_index);
this is called in the function cp/class.c/build_vtbl_initializer
int the gcc. There you could set the function pointers.

mike






>  I know how to do
> all of 
> this except play with the Qt vtable in native code ...

Well, please send me an example of that. 

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<




More information about the kde-core-devel mailing list