From: xunxun <xun...@gm...> - 2011-10-19 04:30:03
Attachments:
gcc-plugin.patch
export-symbols.diff
|
Hi, all I built gcc with "--enable-plugin" on windows. download link: https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z There is an example in the package, and this is in the example directory. Makefile.gcc is linked with cc1 Makefile.g++ is linked with cc1plus So the gcc has some problems, when you use gcc to call plugin, you should link plugin with libcc1.a, and if you use g++ to call plugin, you should link plugin with libcc1plus.a. You can't mix linking, or you will get segment fault. Here is the patches and build process. (I only use C/C++/Fortran, so only modify them) Before building it, you should have dlopen/dlsym, here we can use dlfcn-win32 temporarily. 1. Make binutils export exe's symbols. Patch binutils using export-symbols.diff And using the newer binutils to build gcc. 2. Modify gcc source code to support plugin Patch gcc using gcc-plugin.patch 3. Build gcc using --enable-plugin 4. After installing, you should copy libcc1.a, libcc1plus.a and libf951.a to your install directory's lib. Then you can use gcc plugin. Note: when you use gcc to call plugin, you should link plugin with libcc1.a, and if you use g++ to call plugin, you should link plugin with libcc1plus.a. You can't mix linking, or you will get segment fault. In the end, I use the built editon to run the gcc testsuite plugin section successfully. So, at some time, we can port llvm-dragonegg to windows? Any ideas? Thanks. -- Best Regards, xunxun |
From: asmwarrior <asm...@gm...> - 2011-10-19 04:54:03
|
On 2011-10-19 12:29, xunxun wrote: > Hi, all > > I built gcc with "--enable-plugin" on windows. > > download link: > https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z > > There is an example in the package, and this is in the example directory. > Makefile.gcc is linked with cc1 > Makefile.g++ is linked with cc1plus > > So the gcc has some problems, when you use gcc to call plugin, you > should link plugin with libcc1.a, and if you use g++ to call plugin, > you should link plugin with libcc1plus.a. You can't mix linking, or > you will get segment fault. > > > Here is the patches and build process. (I only use C/C++/Fortran, so only modify them) > > Before building it, you should have dlopen/dlsym, here we can use > dlfcn-win32 temporarily. > > 1. Make binutils export exe's symbols. > Patch binutils using export-symbols.diff > And using the newer binutils to build gcc. > > 2. Modify gcc source code to support plugin > Patch gcc using gcc-plugin.patch > > 3. Build gcc using --enable-plugin > > 4. After installing, you should copy libcc1.a, libcc1plus.a and > libf951.a to your install directory's lib. > > Then you can use gcc plugin. > > Note: when you use gcc to call plugin, you should link plugin with > libcc1.a, and if you use g++ to call plugin, you should link plugin > with libcc1plus.a. You can't mix linking, or you will get segment > fault. > > In the end, I use the built editon to run the gcc testsuite plugin section successfully. > > So, at some time, we can port llvm-dragonegg to windows? > > Any ideas? > > Thanks. > > > Great Job. I'm expecting this for a long time. Here is my test to print the top level of the declaration in a main.cpp file. -------------------------------------------------------- E:\code\cb\gcc\MinGW_GCC4.6.1_enable_plugin_experimental\example>g++ -fplugin=he llo.dll main.cpp starting hello processing main.cpp type_decl ::foo at main.cpp:2 template_decl ::templ at main.cpp:11 type_decl ::typedefed_int_t at main.cpp:21 function_decl ::main at main.cpp:23 ... --------------------------------------------------------- The source code to build the plugin I use is in: http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-cxx-with-gcc-plugin-part-2/ The main.cpp file is below: ------------------------------------------- struct foo { int bar; int baz; void hello(int x, int y) {} void bye(char* x, char* y); }; template<class T> struct templ { T* x; }; void foo::bye(char* x, char* y) { } typedef int typedefed_int_t; int main() { return 0; } ---------------------------------------------- asmwarrior ollydbg from codeblocks' forum |
From: AndrejMitrovic <and...@gm...> - 2013-06-11 21:19:27
|
xunxun wrote > Hi, all > > I built gcc with "--enable-plugin" on windows. > > download link: > https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z Hello, Has anyone had success building with --enable-plugin with MinGW 4.8.0? I'm interested in getting it to work to use gccxml-plugin[1]. Currently when I try to build with the plugin switch I get back the error: "Building GCC with plugin support requires a host that supports -fPIC, -shared, -ldl and -rdynamic." This is after I've manually applied the 4.6.1 patches xunxun provided to 4.8.0 sources. [1] : https://github.com/alexleach/gccxml_plugin -- View this message in context: http://mingw.5.n7.nabble.com/gcc-enable-plugin-experimental-built-on-windows-tp14088p31690.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: xunxun <xun...@gm...> - 2013-06-13 01:54:18
|
于 2013/6/12 5:19, AndrejMitrovic 写道: > xunxun wrote >> Hi, all >> >> I built gcc with "--enable-plugin" on windows. >> >> download link: >> https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z > Hello, > > Has anyone had success building with --enable-plugin with MinGW 4.8.0? I'm > interested in getting it to work to use gccxml-plugin[1]. Currently when I > try to build with the plugin switch I get back the error: > > "Building GCC with plugin support requires a host that supports -fPIC, > -shared, -ldl and -rdynamic." > > This is after I've manually applied the 4.6.1 patches xunxun provided to > 4.8.0 sources. > > [1] : https://github.com/alexleach/gccxml_plugin > > > > -- > View this message in context: http://mingw.5.n7.nabble.com/gcc-enable-plugin-experimental-built-on-windows-tp14088p31690.html > Sent from the MinGW - User mailing list archive at Nabble.com. > I haven't built 4.8 using --enable-plugin I don't know whether you have used the patch similar below: diff -ruNa gcc4.6.1/gcc/configure build/gcc/configure --- gcc4.6.1/gcc/configure 2011-02-28 23:36:37.000000000 +0800 +++ build/gcc/configure 2011-10-16 20:57:13.000000000 +0800 @@ -26270,10 +26270,11 @@ ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null 2>&1 if $export_sym_check conftest | grep foobar > /dev/null; then plugin_rdynamic=yes - pluginlibs="-rdynamic" + pluginlibs="-Wl,--export-all-symbols" else - plugin_rdynamic=no - enable_plugin=no + plugin_rdynamic=yes + enable_plugin=yes + pluginlibs="-Wl,--export-all-symbols" fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $plugin_rdynamic" >&5 $as_echo "$plugin_rdynamic" >&6; } @@ -26364,7 +26365,7 @@ $as_echo_n "checking for -fPIC -shared... " >&6; } cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ -extern int X; +int X; int main () { The patch will pass -fPIC, -shared, -ldl and -rdynamic detect. -- Best Regards, xunxun |
From: asmwarrior <asm...@gm...> - 2013-06-12 02:03:45
|
On 2013-6-12 5:19, AndrejMitrovic wrote: > xunxun wrote >> Hi, all >> >> I built gcc with "--enable-plugin" on windows. >> >> download link: >> https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z > > Hello, > > Has anyone had success building with --enable-plugin with MinGW 4.8.0? I'm > interested in getting it to work to use gccxml-plugin[1]. Currently when I > try to build with the plugin switch I get back the error: > > "Building GCC with plugin support requires a host that supports -fPIC, > -shared, -ldl and -rdynamic." > > This is after I've manually applied the 4.6.1 patches xunxun provided to > 4.8.0 sources. > > [1] : https://github.com/alexleach/gccxml_plugin > Hi, great to hear that you are going to try this. For your problem, if I remember correctly, xunxun has manually disable this configure check on "-rdynamic", but I don't know how he did this, maybe he just comment out the statement in configure script. I CC xunxun, so he may give response. Asmwarrior |
From: AndrejMitrovic <and...@gm...> - 2013-06-12 02:24:57
|
On 6/12/13, Yuanhui Zhang [via MinGW] <ml-...@n7...> wrote: > For your problem, if I remember correctly, xunxun has manually disable this > configure check on "-rdynamic", but I don't know how he did this, maybe he > just comment out the statement in configure script. That seems like a simple way to do it. I'll give it a shot and report back. -- View this message in context: http://mingw.5.n7.nabble.com/gcc-enable-plugin-experimental-built-on-windows-tp14088p31692.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Andrej M. <and...@gm...> - 2013-06-12 14:51:11
|
On 6/12/13, AndrejMitrovic <and...@gm...> wrote: > That seems like a simple way to do it. I'll give it a shot and report back. I gave this a shot, but I ran into a problem: - libcc1plus.a was not generated, also I can see the .def file is empty too. I think the problem might be that I was using an existing MinGW toolchain for the build which didn't have the patched binutils which exports all symbols. - Also gcc-plugin.h and config.h were not placed in the MinGW\i686-w64-mingw32\include folder after building, but I don't think this is a problem, I can simply copy them over or use custom include flags to the GCC source where they're located. When trying to build xunxun's example plugin project the only real problem now is the missing libcc1plus.a (without it I'll get undefined symbol errors, of course). This is how I built GCC 4.8.0 with plugin support: I've used the mingw-builds[1] script to automatically build GCC 4.8.0., it requires MSYS with a specific set of tools, but the Github readme has a link to the packaged MSYS binary so it's not an issue. The way it works is it downloads the x32 and x64 pre-built toolchains to build GCC with. It also downloads all sources after running and before building. It generates empty "marker" files when something is built, so you can restart the script at any point without having to build everything from scratch. [1] : https://github.com/niXman/mingw-builds Fist I've applied xunxun's binutils patches. Then I've started the build process with: $ ./build gcc-4.8.0 x32 The build script then built binutils and some other projects (bzip, zlib, etc). Then at the GCC build step (after the patching and configure step) of the mingw-builds script I would stop the build with CTRL+C and then I manually applied xunxun's GCC 4.6.0 patch over the 4.8.0 source. The reason why I did it this way is because mingw-builds script applies its own set of patches over the GCC source, so I had to manually apply xunxun's GCC patch after this. (If I did it beforehand I might have ran into patching errors..) The one difference when applying xunxun's GCC patch is that cc1-checksum.o has moved from 4.6.0's "/gcc/Makefile.in" file to 4.8.0's "gcc/c/Make-Lang.in" file. Then in the gcc/configure file I've removed this following section to avoid erroring out when I build with plugin support: ----- if test x"$enable_plugin" = x"no" ; then if test x"$default_plugin" != x"yes"; then as_fn_error " Building GCC with plugin support requires a host that supports -fPIC, -shared, -ldl and -rdynamic." "$LINENO" 5 fi fi ----- And I've replaced this section: ----- # Check whether --enable-plugin was given. if test "${enable_plugin+set}" = set; then : enableval=$enable_plugin; enable_plugin=$enableval else enable_plugin=yes; default_plugin=yes fi ----- with this: ----- enable_plugin=yes; default_plugin=yes ----- I didn't know how else to pass --enable-plugin to the configure script because mingw-builds doesn't have that option and it runs ./configure on its own. Then I've deleted a "configure" marker file somewhere in the build directory of GCC (the folder was named "x32-480-posix-sjlj") to force the mingw-builds script to re-configure GCC again. After that the build script started building GCC and it built it successfully, but some sub-projects failed to build: Python failed to link, LD reported: ----- c:/msys/home/administrator/x32-480-posix-sjlj/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe: final link failed: File truncated ----- And GDB didn't build because it was built the flag --with-python, but Python failed to link above. Also the post-build test stdthread_test.exe failed on both x32 and x64 with this log: ----- This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted ----- Anyway GDB and Python and that test-case are not important here, you can simply copy over "marker" files to make the script believe the builds were successful to continue building other sub-projects. So, I need to figure out a way to generate libcc1plus.a. I guess I'll have to rebuild GCC 4.8.0 again but with a toolchain with the patched binutils. I'll give this another go today, *fingers crossed*. |
From: Andrej M. <and...@gm...> - 2013-06-12 14:55:32
|
On 6/12/13, Andrej Mitrovic <and...@gm...> wrote: > After that the build script started building GCC and it built it > successfully Oh and I've verified that `gcc -v` shows that it was indeed built with --enable-plugin. |
From: Eli Z. <el...@gn...> - 2013-06-12 17:06:41
|
> Date: Wed, 12 Jun 2013 16:51:04 +0200 > From: Andrej Mitrovic <and...@gm...> > > - libcc1plus.a was not generated, also I can see the .def file is > empty too. I think the problem might be that I was using an existing > MinGW toolchain for the build which didn't have the patched binutils > which exports all symbols. I know nothing about GCC plugin architecture, but do you really need to export all symbols? Doesn't a plugin have a well-defined API to use? If it does, then all you need is to export only those symbols that are needed to access that API. To that end, the steps are: . Using some trivial cpp magic, mark each of those symbols __declspec(dllexport) when they are used to compile GCC, but __declspec(dllimport) when you compile plugins. This usually belongs to some header file that both GCC and the plugins include. . Rebuild GCC after adding -Wl,--out-implib=SOMETHING.dll.a to the link command line. This will create an import library that your plugins will need to be linked against. That's it! Apologies if my ignorance caused me to write nonsense. > When trying to build xunxun's example plugin project the only real > problem now is the missing libcc1plus.a (without it I'll get undefined > symbol errors, of course). The usual convention for an import library name is libcc1plus.dll.a, although GCC supports other names as well. |
From: Andrej M. <and...@gm...> - 2013-06-12 17:50:01
|
On 6/12/13, Eli Zaretskii <el...@gn...> wrote: > I know nothing about GCC plugin architecture, but do you really need > to export all symbols? Doesn't a plugin have a well-defined API to > use? If it does, then all you need is to export only those symbols > that are needed to access that API. To that end, the steps are: > > . Using some trivial cpp magic, mark each of those symbols > __declspec(dllexport) when they are used to compile GCC, but > __declspec(dllimport) when you compile plugins. This usually > belongs to some header file that both GCC and the plugins include. > > . Rebuild GCC after adding -Wl,--out-implib=SOMETHING.dll.a to the > link command line. This will create an import library that your > plugins will need to be linked against. > > That's it! > Yeah, that makes sense, I know about those tricks. The GCC guys probably rely on the fact all symbols are exported on Posix (win32 works differently). I hope that's the only real issue with plugin support on win32. If the current build fails I'll have a look at which symbols are used for the plugin architecture and use macros to export them. On 6/12/13, Eli Zaretskii <el...@gn...> wrote: > Apologies if my ignorance caused me to write nonsense. Not at all, it's just that I was trying to follow the initial guide before attempting to do anything different. Thanks! |
From: Andrej M. <and...@gm...> - 2013-06-12 19:40:59
|
On 6/12/13, Andrej Mitrovic <and...@gm...> wrote: > Not at all, it's just that I was trying to follow the initial guide > before attempting to do anything different. Thanks! Well, patching binutils didn't work. For one thing building x32-mingw-w64-crt-multi failed: ----- dlltool.exe: Can't create .lib file: lib64/libkernel32.a: Invalid bfd target ----- And it fails like that for every 64bit library. I don't need the 64bit binaries, the mingw-builds script wants to build them for some reason even though I specifically only target x32 builds. But even if I ignore this, building GCC also fails with: ----- libgcc.a: could not read symbols: Archive has no index; run ranlib to add one ----- So I'll give a shot at using non-patched binutils and try to explicitly export symbols. |
From: xunxun <xun...@gm...> - 2013-06-13 01:57:59
|
于 2013/6/13 3:40, Andrej Mitrovic 写道: > On 6/12/13, Andrej Mitrovic <and...@gm...> wrote: >> Not at all, it's just that I was trying to follow the initial guide >> before attempting to do anything different. Thanks! > Well, patching binutils didn't work. For one thing building > x32-mingw-w64-crt-multi failed: Can you use a solo x86/(x64?) toolchain but not a multi-lib toolchain? I only test it on x86 gcc toolchains. > > ----- > dlltool.exe: Can't create .lib file: lib64/libkernel32.a: Invalid bfd target > ----- > > And it fails like that for every 64bit library. I don't need the 64bit > binaries, the mingw-builds script wants to build them for some reason > even though I specifically only target x32 builds. > > But even if I ignore this, building GCC also fails with: > > ----- > libgcc.a: could not read symbols: Archive has no index; run ranlib to add one > ----- > > So I'll give a shot at using non-patched binutils and try to > explicitly export symbols. > > -- Best Regards, xunxun |