Fwd: GCC front end and GCC internals
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
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 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
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 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 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 &
help with front end and scopes
I am a bit stuck on global, file and local name spaces and scopes.
Normally my expression bindings is associated with a function, which
makes the function the scope of all the variables.
my front end can parse something like this:
int testfunc(int parmVar)
{
int testfuncVar;
}
int testfunc2(int funcVar)
{
int testfuncVar2;
}
Every function is individually gimplified and added and finalized.
Everything is chained and bind correctly.
parser->Fndecl = build_fn_decl(functionName, fnDeclType);
gimplify_function_tree(parser->Fndecl);
cgraph_node::finalize_function(parser->Fndecl, true);
I want to expand my front end to something like this:
module TestModule
{
int moduleVariable;
class TestClass
{
int classVariable;
int testfunc(int parmVar)
{
int testfuncVar;
}
}
}
The question is what should TestModule be declared as, what tree type
or declaration function, and also TestClass. How should TestModule be
gimplified and then finalized.
Thank you
André
Re: help with front end and scopes
Thanks for the help. I just want to elaborate just a bit.
So if I understand it correctly, only the function in my case are
gimplified or the starting point.
Lets say I initialised classVariable 10 outside a function.
tree setVariable = build2(INIT_EXPR, void_type_node,
classVariableDecl, build_int_cst_type(integer_type_node, 10));
assume setVariable ends up in the statement list of TestClass correctly.
Does it means that gcc will follow the chain from testFunc to
TestClass (DECL_CONTEXT(testFunc) = TestClass) and then follows the
stament list of TestClass ending up initialising classVariable by only
submitting testFunc to gimple?
Regards,
André
On Wed, Apr 12, 2017 at 10:36 AM, Richard Biener
wrote:
> On April 12, 2017 10:24:31 AM GMT+02:00, Andre Groenewald
> wrote:
>>I am a bit stuck on global, file and local name spaces and scopes.
>>
>>Normally my expression bindings is associated with a function, which
>>makes the function the scope of all the variables.
>>
>>my front end can parse something like this:
>>
>>int testfunc(int parmVar)
>>{
>> int testfuncVar;
>>}
>>
>>int testfunc2(int funcVar)
>>{
>> int testfuncVar2;
>>}
>>
>>Every function is individually gimplified and added and finalized.
>>Everything is chained and bind correctly.
>>
>>parser->Fndecl = build_fn_decl(functionName, fnDeclType);
>>
>>gimplify_function_tree(parser->Fndecl);
>>cgraph_node::finalize_function(parser->Fndecl, true);
>>
>>I want to expand my front end to something like this:
>>
>>module TestModule
>>{
>> int moduleVariable;
>> class TestClass
>> {
>>int classVariable;
>>int testfunc(int parmVar)
>>{
>> int testfuncVar;
>>}
>> }
>>}
>>
>>The question is what should TestModule be declared as, what tree type
>>or declaration function, and also TestClass. How should TestModule be
>>gimplified and then finalized.
>
> TestModule should be context of TestClass which should be context of testFunc
> which is the only thing gimplified.
>
> For TestModule you have the choice of NAMESPACE_DECL and
> TRANSLATION_UNIT_DECL.
>
> Richard.
>
>>Thank you
>>André
>
Re: help with front end and scopes
This info is gold. I have much clearer understanding now.
Thanks,
André
On Wed, Apr 12, 2017 at 2:45 PM, Richard Biener
wrote:
> On Wed, Apr 12, 2017 at 2:07 PM, Andre Groenewald
> wrote:
>> Thanks for the help. I just want to elaborate just a bit.
>>
>> So if I understand it correctly, only the function in my case are
>> gimplified or the starting point.
>>
>> Lets say I initialised classVariable 10 outside a function.
>> tree setVariable = build2(INIT_EXPR, void_type_node,
>> classVariableDecl, build_int_cst_type(integer_type_node, 10));
>> assume setVariable ends up in the statement list of TestClass correctly.
>>
>> Does it means that gcc will follow the chain from testFunc to
>> TestClass (DECL_CONTEXT(testFunc) = TestClass) and then follows the
>> stament list of TestClass ending up initialising classVariable by only
>> submitting testFunc to gimple?
>
> No. You have to add that to the function body. The only way to initialize
> variables outside of function bodies is via DECL_INITIAL and that only
> works for globals and constant initializers.
>
> Richard.
>
>> Regards,
>> André
>>
>> On Wed, Apr 12, 2017 at 10:36 AM, Richard Biener
>> wrote:
>>> On April 12, 2017 10:24:31 AM GMT+02:00, Andre Groenewald
>>> wrote:
>>>>I am a bit stuck on global, file and local name spaces and scopes.
>>>>
>>>>Normally my expression bindings is associated with a function, which
>>>>makes the function the scope of all the variables.
>>>>
>>>>my front end can parse something like this:
>>>>
>>>>int testfunc(int parmVar)
>>>>{
>>>> int testfuncVar;
>>>>}
>>>>
>>>>int testfunc2(int funcVar)
>>>>{
>>>> int testfuncVar2;
>>>>}
>>>>
>>>>Every function is individually gimplified and added and finalized.
>>>>Everything is chained and bind correctly.
>>>>
>>>>parser->Fndecl = build_fn_decl(functionName, fnDeclType);
>>>>
>>>>gimplify_function_tree(parser->Fndecl);
>>>>cgraph_node::finalize_function(parser->Fndecl, true);
>>>>
>>>>I want to expand my front end to something like this:
>>>>
>>>>module TestModule
>>>>{
>>>> int moduleVariable;
>>>> class TestClass
>>>> {
>>>>int classVariable;
>>>>int testfunc(int parmVar)
>>>>{
>>>> int testfuncVar;
>>>>}
>>>> }
>>>>}
>>>>
>>>>The question is what should TestModule be declared as, what tree type
>>>>or declaration function, and also TestClass. How should TestModule be
>>>>gimplified and then finalized.
>>>
>>> TestModule should be context of TestClass which should be context of
>>> testFunc which is the only thing gimplified.
>>>
>>> For TestModule you have the choice of NAMESPACE_DECL and
>>> TRANSLATION_UNIT_DECL.
>>>
>>> Richard.
>>>
>>>>Thank you
>>>>André
>>>
how to make GCC option hook aware
Hi GCC folks,
I have implemented a function for LANG_HOOKS_HANDLE_OPTION for my toy
language front end to handle options.
The specific option is populated in lang.opt as fdemo-debug
My lang-specs file has the following: {"@demo", "demo1 %i
%(cc1_options) %{!fsyntax-only:%(invoke_as)}", 0, 1, 0},
Everything compiles and the front end gets invoked. GCC even suggest
the correct the flag when mistyped, but my function
demo_langhook_handle_option doesn't get invoked.
What else do I need to implement to get this working.
Thanks
Re: how to make GCC option hook aware
I followed your advice and every works great.
Thank you,
André
On Mon, Feb 19, 2018 at 5:25 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 17 Feb 2018, Andre Groenewald wrote:
>
>> Hi GCC folks,
>>
>> I have implemented a function for LANG_HOOKS_HANDLE_OPTION for my toy
>> language front end to handle options.
>>
>> The specific option is populated in lang.opt as fdemo-debug
>>
>> My lang-specs file has the following: {"@demo", "demo1 %i
>> %(cc1_options) %{!fsyntax-only:%(invoke_as)}", 0, 1, 0},
>>
>> Everything compiles and the front end gets invoked. GCC even suggest
>> the correct the flag when mistyped, but my function
>> demo_langhook_handle_option doesn't get invoked.
>>
>> What else do I need to implement to get this working.
>
> Have you also implemented the LANG_HOOKS_OPTION_LANG_MASK hook? That
> selects which options for which languages are actually fed to the other
> hook. Your lang.opt needs to specify the language as well (say Foo), then
> your lang_mask hook needs to include at least CL_Foo (a bit mask). See
> e.g. the simple implementation in brig and lto.
>
>
> Ciao,
> Michael.
Re: GCC contribution
The heart of GCC should remain pure C as far as possible, for the very same reason the Linux kernel is only in C. Deviate from this, and in a few years we will end up with Java as the programming language of GCC. It is the duty of the steering community and our leaders in GCC to be very conservative in this regard. Please I don't want to oppose someone’s proposal, I want the people to understand reason of being conservative in this regard, because they will end up being the leaders of GCC in the following generations. GCC steering community I count on you and speaking behalf other developers to keep GCC as close to C as possible for at least the next 1000 years. On Thu, Mar 29, 2018 at 12:15 AM, Katsunori Kumatani wrote: > Please don't change the lang_hooks into virtual methods. Speaking from a > plugin development viewpoint, C hooks are very easy to override > individually, without having to change the entire object or create a new > one. > > I realize that it's not the intended use for the hooks, and not why they > were created. But they enable plugins to do a whole lot more, despite the > limited plugin event callbacks already present (*especially* the targetm > hooks!). > > For example, I wanted to add some plugin processing (actually a top-level > asm statement) at the end of a translation unit (with gathered data) to add > some special symbols / GAS directives (not instructions). But there's no > "normal" plugin event for this. > > So instead I simply saved the original lang_hooks.parse_file hook (pointer), > overrode the hook with the plugin's, which calls the original first and then > does whatever plugin does. And it works fine. This kind of thing wouldn't be > easily changed with virtual methods I believe. > > Once again, I realize that was not the intended use for hooks, but it's a > nice side effect and IMO should be kept. > > Plugins suffer a lot from the "chicken and egg" problem (nobody wants to add > events that would not be needed, but nobody codes plugins without enough > events) and hooks kind of solve a lot of it, so that's a good thing > (especially targetm, more so than lang_hooks). > > I mean, if you had to first suggest an event and *hope* it gets added before > even starting your plugin (otherwise it would be a waste of time), you'd > just give up. Or at least, the majority would. At least with hooks, nobody > needs to add anything for plugins, since you can override the C hooks > directly from the plugin (while maintaining a chain for the old one).
Re: GCC contribution
Your prochronistic expression is why front ends is developed.
The purpose of the GCC engine is to make anachronistic futuristic code
executable by means of a front-end, not to implement every star-trek
expression.
Why having this pointless conversation, the Titanic has left the port.
On Fri, Mar 30, 2018 at 2:16 PM, Nathan Sidwell wrote:
> On 03/29/2018 09:48 AM, Jeff Law wrote:
>>
>> On 03/29/2018 12:56 AM, Andre Groenewald wrote:
>
>
>>> GCC steering community I count on you and speaking behalf other
>>> developers to keep GCC as close to C as possible for at least the next
>>> 1000 years.
>>
>> We've already made a decision to use C++ when it makes sense. That ship
>> sailed years ago.
>
>
> Yeah, when can I write something as anachronistically futuristic as:
>
> v.qsort ([](auto a, auto b)
> { return int (**(Obj const *const *)a
><=> **(Obj const *const*)b); });
>
> huh?
>
> nathan
> --
> Nathan Sidwell
