R: R: R: Plugin development under windows

[Davide Piombo <Davide dot Piombo at phase dot eu>]

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.

I tried to link by using the libgcc.a file included in the Arm cross compiler directory but the compiler complains about the different release (Cygwin gcc is 5.4.0 while ARM cross compiler is 6.3.1) and, as far as I know, this problem can be solved only using the same compiler version for build and libraries...

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. 
Just for completeness missing symbols are:
register_scoped_attributes(attribute_spec const*, char const*)
global_dc
global_options
register_callback

Following Joseph's reply I also had a look at gcc plugin source code, effectively there are no OS related conditional build pragmas and the code does not contain dedicated sections to handle the load and unload of dll under Windows.

Unless somebody has a good idea on how to solve these issues I think I will stop my investigations...

I wish to thank all of you for your time and for your help.
I just want to ask to gcc plugin site maintainers to add a note on the site about the fact that actually plugins cannot run on Windows, I think it is an useful info... ;-)

Thanks again to everybody

Davide




> -----Messaggio originale-----
> Da: Trevor Saunders [mailto:tbsaunde@tbsaunde.org]
> Inviato: mercoledì 29 marzo 2017 01:09
> A: Davide Piombo
> Cc: 'Joseph Myers'; David Malcolm; 'gcc@gcc.gnu.org'
> Oggetto: Re: R: R: Plugin development under windows
> 
> On Tue, Mar 28, 2017 at 07:51:47AM +0000, 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:joseph@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
> > > joseph@codesourcery.com