Hi, On Fri, Mar 31, 2017 at 08:56:26AM +0200, Andre Groenewald wrote: > Sorry about the fwd in the description. > > This is my implementation: > > fnDeclType = build_function_type_array(integer_type_node, > argVect.NumOfItems, parmTypes); > tree fnDecl = build_fn_decl(identifier->Str, fnDeclType); > DECL_EXTERNAL(fnDecl) = 1; > fnAddr = build1(ADDR_EXPR, build_pointer_type(fnDeclType), fnDecl); > funcStmt = build_call_array_loc(identifier->Locus, integer_type_node, > fnAddr, argVect.NumOfItems, parms);
for plain function, this seems fine to me. > > It works perfectly for calling functions. Not sure if it is the > preferred way to do it, but gets the job done. > > > ...calling conventions (and anything defied in an Application Binary > > Interface) is of course dependant on the architecture and operating > > system you are compiling for, so you need to tell us that. > > I am not really that interested in calling convention. It only gets > me to realise that methods (non static) and functions are not the > same, even on a binary level. But you do know that methods have an extra (first, actually) parameter containing the this pointer, right? > If I do it "correctly" on generic level GCC will be taking care of everything. > But for what it's worth here is my specs: Intel x86_64, Ubuntu 16.04 > LTS 64bit, gcc 5.2, compiled with g++ I am not a back-end expert but as chance had it, I have recently looked into that that target for divergence in calling conventions between and FUNCTION_TYPEs and METHOD_TYPEs and found none in the 64 bit variant. I'd suggest that you compile both your calling program and the working c++ caller with -fdump-tree-all and look for differences. > > > type of the function being called is METHOD_TYPE and not FUNCTION_TYPE > > (but that is actually good for consistency on any platform). Except > > for static methods, those are functions in gcc internals. > > My implementation generates a FUNCTION_TYPE, is there an easy way to > turn it into a METHOD_TYPE, like a single tree call. > That will take care of consistency. > None that I know of, but there is build_method_type_directly that you should be able ti use instead of build_function_type_array. Martin > > On Thu, Mar 30, 2017 at 4:03 PM, Martin Jambor <mjam...@suse.cz> wrote: > > Hello, > > > > I am not sure if I can help you but... > > > > On Thu, Mar 30, 2017 at 08:05:07AM +0200, Andre Groenewald wrote: > >> I am discovering the awesome world of GCC internals. I managed to > >> develop a basic front end. It can call internal and external functions > >> and link with standard libraries. All is good. > >> > >> The hunger for more does not end. I want to call c++ libraries and > >> interact with c++ objects. > >> > >> My starting point was to call a test c++ method. I created a test c++ > >> class with a test method/function. It was compiled into a library. The > >> library was tested with c++ program and it worked. I manage to call it > >> from my front end, but the parameter I passed was messed up. It was > >> some random value every time I called the method. > >> > >> I disassembled my program and the test c++ program, then compared the > >> two. I found that it uses a different register as in the case when > >> calling a standard c style function. > >> > >> It seems that methods are different in the calling convention than > >> normal functions, which is fine. All that I need to do is set correct > >> tree property and every will work, right? The question is what tree > >> property should I set, which macro should I use to set that property? > >> > > > > ...calling conventions (and anything defied in an Application Binary > > Interface) is of course dependant on the architecture and operating > > system you are compiling for, so you need to tell us that. > > > > Having said that, the only target that I know about that uses > > different argument passing for methods and for functions is > > i686-mingw32 (MS Windows). If that is your case, make sure that the > > type of the function being called is METHOD_TYPE and not FUNCTION_TYPE > > (but that is actually good for consistency on any platform). Except > > for static methods, those are functions in gcc internals. > > > > If this does not help, you'll need to provide much more details about > > your whole setup. > > > > Martin > >
