Fwd: GCC front end and GCC internals

Fwd: GCC front end and GCC internals

[Andre Groenewald]

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?

Please be patient with my English, it is not my first language.

Thank you all in advance.

Re: Fwd: GCC front end and GCC internals

[Martin Jambor]

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

Re: Fwd: GCC front end and GCC internals

[Andre Groenewald]

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);

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.
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++

> 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.

Regards,
André


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
>

Re: Fwd: GCC front end and GCC internals

[Martin Jambor]

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

Re: Fwd: GCC front end and GCC internals

[Andre Groenewald]

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