Fwd: GCC front end and GCC internals

Martin Jambor mjambor@suse.cz
Fri Mar 31 08:00:00 GMT 2017


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



More information about the Gcc mailing list