R: R: R: R: Plugin development under windows
Hi Pedro, thanks a lot for your message, it clarified me a lot of things. Actually I have no time to try to change GCC plugin code to make it working in Windows, in order to solve my problem I will move to another solution, maybe in the future... Cheers Davide > -Messaggio originale- > Da: Pedro Alves [mailto:pe...@palves.net] > Inviato: mercoledì 29 marzo 2017 12:38 > A: Davide Piombo; 'Trevor Saunders' > Cc: 'Joseph Myers'; David Malcolm; 'gcc@gcc.gnu.org' > Oggetto: Re: R: R: R: Plugin development under windows > > On 03/29/2017 08:30 AM, Davide Piombo wrote: > > Hi Trevor, thanks for your hint. > > > > Yesterday I made some other tests. I tried to use CygWin instead of > > MinGW and the POSIX missing references are now solved. Now the error > > have moved from the compiler to the linker and the build stops > because > > of undefined references. The missing symbols are included in GCC > > executable and are declared as external symbols in GCC plugin header > > files. > > Declared as external is not sufficient. They also need to be declared > as exported in PE terms. > > Usually, you do that by tagging exported symbols with > __declspec(dllexport) at the time the exe is built, and tagging them as > __declspec(dllimport) when the plugin is built. > > I.e., you'd apply the guidelines described at: > > https://gcc.gnu.org/wiki/Visibility > > to GCC itself. E.g., add a macro like the DLL_PUBLIC described there, > something around: > > #if defined _WIN32 || defined __CYGWIN__ # ifdef BUILDING_GCC > # define GCC_PUBLIC __declspec(dllexport) > # else > # define GCC_PUBLIC __declspec(dllimport) > # endif > #else > # define GCC_PUBLIC > #endif > > And add GCC_PUBLIC to symbols that should be exported to plugins. > > AFAIK, in plugin architectures on Windows, it's more common to split > the bulk of an exe to a dll that is then linked by both a "shim" exe > and the plugins, but exporting symbols from EXEs should work fine too. > See e.g.,: > > http://stackoverflow.com/questions/3752634/dll-get-symbols-from-its- > parent-loader/3756083#3756083 > http://stackoverflow.com/questions/15454968/dll-plugin-that-uses- > functions-defined-in-the-main-executable > > The key search terms are "plugins on windows export exe symbols". > > My Windows knowledge has been steadily fading over the years, and I'm > not sure whether GCC export all symbols automatically using "- > fvisibility" > on Windows (as workaround) of whether you really need to go the > __declspec or dllexport routes. > > Also, see: > > https://gcc.gnu.org/onlinedocs/gcc/Microsoft-Windows-Function- > Attributes.html > > maybe you can also workaround it by using LD's --export-all. > > This should give you some pointers to experiment. > > > Anyway, before to change the compiler or library version I tried to > > dump symbols from libgcc.a in order to understand if missing symbols > > are really in this library and they are not there. > > libgcc.a is not GCC itself. See: > > https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html > > Thanks, > Pedro Alves
Re: Fwd: GCC front end and GCC internals
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: Obsolete powerpc*-*-*spe*
On Wed, 15 Mar 2017, Andrew Jenner wrote: > > I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC, > > please correct me if that is incorrect. Also, is "normal" floating > > point supported at all? > > My understanding is that SPE is only present in the e500v1, e500v2 and > e200z[3-7] cores, all of which are 32-bit only and do not have classic > floating-point units. SPE and Altivec cannot coexist as they have some > overlapping instruction encodings. The successor to e500v2 (e500mc) reinstated > classic floating-point and got rid of SPE. The VLE ISA does support 64-bit implementations, using the same binary instruction encodings for 64-bit operations as the regular Power ISA (e.g. ldx, ldux, etc.), though I have no idea if such hardware actually exists or has been planned. > > Do some of those also support PowerPC? > > All the e200 cores apart from e200z0 can execute 32-bit instructions as well > as VLE, though we'll always generate VLE code when targetting them (otherwise > they're fairly standard). Many regular Power ISA binary instruction encodings are also supported in the VLE mode, especially where a replacement VLE encoding has not been invented. These include all 3-argument register ALU operations and many more (e.g. stbx, stbux, etc.). The VLE PEM lists over 100 regular Power instruction encodings retained (not counting optional 64-bit operations). So it's not that the VLE instruction set only shares mnemonics with the regular Power instruction set. In fact the opposite is the case: all the mnemonics that have been retained assemble to the same binary machine instructions, then some mnemonics (and their corresponding binary encodings) have been removed and some added (these are prefixed with `e_' for 32-bit binary encodings and `se_' for 16-bit ones). This intersection of the instruction sets was one motivation for keeping the ports together. FWIW, Maciej
gcc-6-20170330 is now available
Snapshot gcc-6-20170330 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170330/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 246600 You'll find: gcc-6-20170330.tar.bz2 Complete GCC SHA256=455f97464a1923ce7eb4233ee4ab85fa53e391f188b13047d5f68f50f55d8e97 SHA1=2c2e51b86716a82852eaad497be1fe37523dcc2a Diffs from 6-20170323 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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 >
