This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gengtype: improved version for plugin support.


On Thu, Sep 17, 2009 at 12:13 AM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Hello All
>
> I am submitting again for review the
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00047.html
>
> I am attaching a slightly improved patch, to trunk rev 151774.
>
>
> As a general point, I believe this patch is much more usable for realistic
> plugins using GGC. As Duncan Sands explained, the current gengtype is very
> buggy in plugin mode for non trivial plugins.
>
> it is quite a simple patch: in every place gengtype is outputting something
> relevant to plugins, I added an additional test, and I record in every
> descriptor of GTY-ed stuff a flag (called in_plugin) which tells if it is
> from the plugin files.
>
>
> As I already mentioned in
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html
>
> * there is an issue with PCH which is partly solved. PCH outputs a tag (in
> the *.gch compiled file of a *.h header passed to gcc), value of the
> generated enum gt_types_enum in gtype-desc.h. we reserve the 0 value (called
> gt_types_enum_firstempty, so the first generated index e.g.
> gt_ggc_e_15interface_tuple in the current trunk is now 1, not 0) f that enum
> to mean don't persist that type. To permit several advanced plugins to
> extend this tagging machinery, we need to make it more dynamic. so, if
> GCC_PLUGIN_HAVE_PCH, we generate a dynamic enum like this:
>
> #ifdef GCC_PLUGIN_HAVE_PCH
> static int gccplugin_type_base;
> #define gt_ggc_e_16basilocalsptr_st
> ((gccplugin_type_base>0)?(gccplugin_type_base+0):0)
> #define gt_ggc_e_13melttriple_st
> ((gccplugin_type_base>0)?(gccplugin_type_base+1):0)
> #define gt_ggc_e_17VEC_melt_ptr_t_gc
> ((gccplugin_type_base>0)?(gccplugin_type_base+2):0)
>
> I hope you guess the "dynamic enumeration" pattern in the geneerated code...
>
> Basically, plugin using GGC won't really work when generating precompiled
> headers, but my patch added an experimental feature to help future patches
> for this. (As I tried to explain in several occasions, generating
> precompiled headers is not currently very compatible with plugins for
> several reasons).

I don't think plugins and PCH will work together ever, so that change is not
needed and only adds additional code.

Richard.

>
> Notice that in plugin mode, the only generated file is the gt-plugin.h file
> passed as a program argument.
>
> In plugin mode, gengtype should be invoked as
> ? gengtype -P gt-outputplugin.h inputplugin.h \
> ? ? ? ? ? ? ? ?inputplugin1.c inputplugin2.c
>
>
> Previous submission of this patch
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00047.html
> contained also a gcc/doc/plugins.texi patch and a gcc/Makefile.in patch.
> Neither are essential (so I will propose them again if asked, or when this
> patch is approved).
>
> gcc/ChangeLog:
> 2009-09-16 ?Basile Starynkevitch ?<basile@starynkevitch.net>
>
> ? ? ? ?* gengtype.c (struct pair, struct type) Added in_plugin field.
> ? ? ? ?(first_plugin_file_ix, plugin_output_filename, plugin_output):
> ? ? ? ?Added static variables.
> ? ? ? ?(is_plugin_file): Added & defined variable.
> ? ? ? ?(output_delayed_functions): Added declaration.
> ? ? ? ?(read_input_list): Manage first_plugin_file_ix and add the plugin
> ? ? ? ?files into gt_files with cleared lang_bitmap.
> ? ? ? ?(string_type, scalar_nonchar, scalar_char): Initialized in_plugin
> ? ? ? ?field.
> ? ? ? ?(new_structure, find_structure, find_param_structure)
> ? ? ? ?(create_pointer, create_array, note_variable): Sets in_plugin.
> ? ? ? ?(create_file): Allocates buf.
> ? ? ? ?(oprintf): Clear s for ease of debugging.
> ? ? ? ?(open_base_files): Moved return when plugins.
> ? ? ? ?(get_output_file_with_visibility): Handle plugin case.
> ? ? ? ?"gtype-desc.c" is for "GCC".
> ? ? ? ?(close_output_files): Free the buffer.
> ? ? ? ?(struct write_types_data): Added is_pch field.
> ? ? ? ?(delay_func_for_structure): new static declaration.
> ? ? ? ?(write_func_for_structure): Emit #ifdef GCC_PLUGIN_HAVE_PCH
> ? ? ? ?wrapping.
> ? ? ? ?(write_types): delays the output of func in plugin mode.
> ? ? ? ?(ggc_wtd, pch_wtd): Sets the is_pch field.
> ? ? ? ?(write_local_func_for_structure): Emit the wrapping & handle
> ? ? ? ?plugin mode.
> ? ? ? ?(write_local): Handle plugin mode.
> ? ? ? ?(write_enum_defn): Emit gt_types_enum_firstempty & emit the
> ? ? ? ?dynamic enumeration #define-s in plugin mode.
> ? ? ? ?(write_roots): Handle plugin mode.
> ? ? ? ?(struct delayedstructfunc_st): New declaration.
> ? ? ? ?(dlystructab, dlystructsiz, dlystructcnt): Added static variables.
> ? ? ? ?(delay_func_for_structure, output_delayed_functions): added
> ? ? ? ?functions.
> ? ? ? ?(main): updated for plugin mode which is now with -P outputfile.h
>
>
> Ok for trunk if it bootstraps?
>
> Regards.
>
> --
> Basile STARYNKEVITCH ? ? ? ? http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]