Re: Fwd: GCC front end and GCC internals

[Andre Groenewald <adres.is.gevat@gmail.com>]

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 <mjambor@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 <mjambor@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
>> >