On Thu, May 25, 2017 at 11:24 AM, augustine.sterl...@gmail.com <augustine.sterl...@gmail.com> wrote: > On Mon, May 22, 2017 at 2:09 PM, Max Filippov <jcmvb...@gmail.com> wrote: >> Now that XCHAL_* macros don't have to be preprocessor constants add >> include/xtensa-dynconfig.h that defines them as fields of a structure >> returned from the xtensa_get_config function. >> Define that structure and fill it with default parameter values >> specified in the include/xtensa-config.h. >> Define reusable function xtensa_load_config that tries to load >> configuration and return an address of an exported object from it. >> Define the function xtensa_get_config that uses xtensa_load_config to >> get structure xtensa_config, either dynamically configured or the >> default. >> >> 2017-05-22 Max Filippov <jcmvb...@gmail.com> >> gcc/ >> * Makefile.in (PLUGIN_HEADERS): Add include/xtensa-dynconfig.h. >> * config.gcc (xtensa*-*-*): Add xtensa-config.o to extra_objs. >> * gcc/config/xtensa/t-xtensa (xtensa-config.o): New rule. >> * gcc/config/xtensa/xtensa-config.c: New file. >> * gcc/config/xtensa/xtensa.h (xtensa-config.h): Replace #include >> with xtensa-dynconfig.h >> (XCHAL_HAVE_MUL32_HIGH, XCHAL_HAVE_RELEASE_SYNC, >> XCHAL_HAVE_S32C1I, XCHAL_HAVE_THREADPTR, >> XCHAL_HAVE_FP_POSTINC): Drop definitions. > > This almost certainly should go through the normal gcc plugin > mechanism instead of the hand-rolled one you have here. > > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins > > If there is a reason it can't (and I'm not sufficiently familiar with > the issues here), then you need to ensure that the various protections > enforced by the normal plugin mechanism is used--and someone more > knowledgeable than me needs to review it.
(adding Le-Chun Wu, current reviewer of the plugin code) I tried to use plugins initially, but the following considerations made me lean towards this implementation: - we don't actually need any of the functionality available to gcc plugins, we only need to provide a data structure that the compiler knows how to use; - using environment variable makes configuration transparent for gcc, all binutils and gdb, whereas using gcc plugin would require changing gcc invocation command line, which is not always possible; - this implementation is shared between gcc and binutils. OTOH using plugin with gcc suggests using plugin with binutils, where it's substantially different and not universally supported across different binutils components (particularly neither assembler nor objdump have any support for it); - gcc does not support plugins when built for windows host using MinGW; Does the above justify this implementation? If no, are there any suggestions how the above points may be addressed? > Please note that by using a plugin mechanism, there are licensing > issues that come into play, that are different from the usual > licensing issues. I would be absolutely sure that you all are OK with > how the runtime exception applies to this new situation. All code used for building the configuration shared object is either GPL (part of binutils) or MIT (xtensa configuration overlay), so it should be ok? -- Thanks. -- Max
