R: R: Plugin development under windows
Hi Joseph, OK, thanks, now it clear to me your point. I do not know what the GCC plugin code really contains and I trust you when you say that GCC plugin section is not ready to handle dll on windows. But I still have two points that are not clear to me: 1- I found some historical references about the fact that exists a porting of dragonegg GCC plugin to Windows (dated 2011 running on GCC 4.6.1) that, following the description provided, has been obtained simply changing some parts of the GCC configure script. I tried to follow the instructions reported updating the configure script but without success. Does the problem is a different implementation of GCC plugin handling code in actual version? You can find the references of the dragonegg porting here: https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc 2- It is my opinion that there are some other problems than the dll handling. What I found trying to rebuild the plugin on windows is that the plugin doesn't build at all, and that the errors are not related to dll handling features. This drives me to think that in order to build a plugin where Windows is the Host for a GCC build it is necessary to do some other changes. What do you think about that? Thanks in advance Davide > -Messaggio originale- > Da: Joseph Myers [mailto:jos...@codesourcery.com] > Inviato: lunedì 27 marzo 2017 18:56 > A: Davide Piombo > Cc: David Malcolm; 'gcc@gcc.gnu.org' > Oggetto: Re: R: Plugin development under windows > > On Mon, 27 Mar 2017, Davide Piombo wrote: > > > Sorry but it is not clear to me if the point is that the plugin > > development must include some windows-related code that I'm actually > > missing or if the problem is on the GCC side, that is inside GCC the > > code section that loads the dll, or part of it, is missing and it is > > still to be implemented. > > GCC only knows about how to dynamically load ELF shared libraries on a > Unix-like operating system. It does not know anything about whatever > interfaces Windows provides to load DLLs. > > GCC assumes a shared library can access symbols dynamically exported by > its internal cc1 and cc1plus executables. I've heard that DLLs work > differently (without an equivalent of -rdynamic), such that for a DLL > to access GCC-internal functions the whole of cc1/cc1plus would instead > need to be moved into a DLL. > > This requires someone with expertise on the relevant Windows facilities > (and probably significant cross-platform expertise as well, since you > need to adapt the build system and plugin support to do the required > things for each platform) to implement the support in GCC for plugins > on Windows host. > > -- > Joseph S. Myers > jos...@codesourcery.com
A "newbies" guide to hacking on GCC (and plugins)
I'm a relative newcomer to GCC [1], so I thought it would be a good idea to try to capture some of the "gotchas" and similar information on hacking on GCC in the form of a short guide for new contributors, whilst the experience of learning it is still fresh in my mind. The guide can be read here: https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html I've mostly tried to cover specific things I ran into that caused me difficulty, so it may be eclectic. (All opinions are my own) I hope that this is useful. Dave [1] did we miss GCC's 30th anniversary? https://gcc.gnu.org/wiki/History says the first release was 1987-03 -22. As for myself, Thursday appears to be the 6th anniversary of me starting the gcc-python-plugin and hence on poking at GCC's internals - I'm not sure if 6 years means I still count as a newcomer, but 30 years is geological epochs in software terms :)
gcc-5-20170328 is now available
Snapshot gcc-5-20170328 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170328/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 246555 You'll find: gcc-5-20170328.tar.bz2 Complete GCC SHA256=a7e49682cad5a46b3c04b89483b8ec0317852cdef782bf7937df160d130b810f SHA1=f77f7d8238ed98fbd7840e0a252eaaa7f75c6e90 Diffs from 5-20170321 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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: R: R: Plugin development under windows
On Tue, Mar 28, 2017 at 07:51:47AM +, Davide Piombo wrote: > Hi Joseph, > OK, thanks, now it clear to me your point. > I do not know what the GCC plugin code really contains and I trust you when > you say that GCC plugin section is not ready to handle dll on windows. > But I still have two points that are not clear to me: > > 1- I found some historical references about the fact that exists a porting of > dragonegg GCC plugin to Windows (dated 2011 running on GCC 4.6.1) that, > following the description provided, has been obtained simply changing some > parts of the GCC configure script. I tried to follow the instructions > reported updating the configure script but without success. > Does the problem is a different implementation of GCC plugin handling code in > actual version? > You can find the references of the dragonegg porting here: > https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc > > 2- It is my opinion that there are some other problems than the dll handling. > What I found trying to rebuild the plugin on windows is that the plugin > doesn't build at all, and that the errors are not related to dll handling > features. > This drives me to think that in order to build a plugin where Windows is the > Host for a GCC build it is necessary to do some other changes. > What do you think about that? >From your errors about posix headers, and since gcc also uses those I suspect your mingw enviroment is not setup correctly. Trev > > Thanks in advance > Davide > > > > -Messaggio originale- > > Da: Joseph Myers [mailto:jos...@codesourcery.com] > > Inviato: lunedì 27 marzo 2017 18:56 > > A: Davide Piombo > > Cc: David Malcolm; 'gcc@gcc.gnu.org' > > Oggetto: Re: R: Plugin development under windows > > > > On Mon, 27 Mar 2017, Davide Piombo wrote: > > > > > Sorry but it is not clear to me if the point is that the plugin > > > development must include some windows-related code that I'm actually > > > missing or if the problem is on the GCC side, that is inside GCC the > > > code section that loads the dll, or part of it, is missing and it is > > > still to be implemented. > > > > GCC only knows about how to dynamically load ELF shared libraries on a > > Unix-like operating system. It does not know anything about whatever > > interfaces Windows provides to load DLLs. > > > > GCC assumes a shared library can access symbols dynamically exported by > > its internal cc1 and cc1plus executables. I've heard that DLLs work > > differently (without an equivalent of -rdynamic), such that for a DLL > > to access GCC-internal functions the whole of cc1/cc1plus would instead > > need to be moved into a DLL. > > > > This requires someone with expertise on the relevant Windows facilities > > (and probably significant cross-platform expertise as well, since you > > need to adapt the build system and plugin support to do the required > > things for each platform) to implement the support in GCC for plugins > > on Windows host. > > > > -- > > Joseph S. Myers > > jos...@codesourcery.com
Re: A "newbies" guide to hacking on GCC (and plugins)
On Tue, Mar 28, 2017 at 04:41:29PM -0400, David Malcolm wrote: > I'm a relative newcomer to GCC [1], so I thought it would be a good > idea to try to capture some of the "gotchas" and similar information on > hacking on GCC in the form of a short guide for new contributors, > whilst the experience of learning it is still fresh in my mind. This seems useful, though I generally think spreading docs around leads to many out of date docs, and further that its much better to make something self explanatory rather than documenting it. > The guide can be read here: > https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html > > I've mostly tried to cover specific things I ran into that caused me > difficulty, so it may be eclectic. I think one thing its useful for is seeing what people have trouble with so we can try and fix them. Here's a list of things I'm comming up with from your docs. ggc I think we already knew this caused grief ;-) I'm very tempted to rip out pch at the start of stage 1 in the hope the C++-modules branch will get merged and we can use that as a PCH replacement. There are probably other things we can do to make ggc more pleasent too. debugging with the driver, I'm not sure we can really do much there, but if you are on x86 and can use rr it hardly matters and the other work arounds are fine. non ggc memory management I think we can make a lot safer with C++ and so make valgrind use much less necessary. option flag "globals" we should probably do something about? but I don't know what at the moment. running the test suite, imho the runtest UI as exposed through make is terrible and unhelpful in error cases. I'm not sure what the full "right" solution is, but this should be improvable with work. Trev > > (All opinions are my own) > > I hope that this is useful. > > Dave > > > [1] did we miss GCC's 30th anniversary? > https://gcc.gnu.org/wiki/History says the first release was 1987-03 > -22. As for myself, Thursday appears to be the 6th anniversary of me > starting the gcc-python-plugin and hence on poking at GCC's internals - > I'm not sure if 6 years means I still count as a newcomer, but 30 years > is geological epochs in software terms :)
