R: R: R: Plugin development under windows

[Davide Piombo]

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:tbsau...@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 +, 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 pl

Re: R: R: R: Plugin development under windows

[Pedro Alves]

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: A "newbies" guide to hacking on GCC (and plugins)

[Jonathan Wakely]

On 28 March 2017 at 21:41, David Malcolm wrote:
> [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 :)

I think Jakub mentioned GCC's anniversary on IRC the day before, but I
still forgot to send it a card.

Fwd: GCC front end and GCC internals

[Andre Groenewald]

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.