What a blunder. > But you do know that methods have an extra (first, actually) parameter > containing the this pointer, right?
I totally missed it. Thank you for informing me. I tested it with a dummy parameter. The dummy parameter taking the place of the this pointer. It worked perfectly. Obviously, for consistency I will rather use METHOD_TYPE than FUNCTION_TYPE when calling methods. > 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. It looked into build_method_type_directly and it seems it automatically add this parameter. I will just use it then. Thanks again for all the help. Regards, André On Fri, Mar 31, 2017 at 10:00 AM, Martin Jambor <mjam...@suse.cz> wrote: > 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 >> >
