[PATCH] D21385: Adjust Registry interface to not require plugins to export a registry

[Rudy Pons via cfe-commits]

Ilod added a subscriber: Ilod.
Ilod added a comment.

Hello,

When I tried your patch and added LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, I had multiple errors on your python scripts, like:

    File "utils/extract_symbols.py", line 399, in <module>
      calling_convention_decoration = is_32bit_windows(libs[0])
    File "utils/extract_symbols.py", line 88, in dumpbin_is_32bit_windows
      match = re.match('.+machine \((\S+)\)', line)
    File "C:\Program Files\Python35\lib\re.py", line 163, in match
      return _compile(pattern, flags).match(string)
  TypeError: cannot use a string pattern on a bytes-like object

And after I fixed them by passing bytes-like object literals, I had the following error:

    File "utils/extract_symbols.py", line 488, in <module>
      print >>outfile, str(k)
  TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' and '_io.TextIOWrapper'

I gave up after this. I have Pyhton 3.5 64 bits, and was building clang 32-bits on Windows with Visual Studio 2015 Update 2.

Looking at the patch:

If I understand correctly, the pros/cons between your approach and the previous attempt are:

- Your method allows to export the various symbols of the tool from the plugin, allowing mainly to access/modify global variables of it, instead of having another instance of it in the DLL (thus probably causing many bugs)
- Previous attempt allowed to make a plugin which could be loaded by any tool, while yours need the plugin to be specific to a tool

If that's all, I suppose it's better to have your limitation to plugin support rather than a full support which will bug if you call a function that accesses a static member.

(By the way, the previous attempt works fine, it was reverted because of a mingw crash which can be fixed by the patch http://reviews.llvm.org/D18847)

However, couldn't we enable by default LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on the platforms/compilers which doesn't currently support the plugins? Having plugins only work on custom builds of clang seems to be against the main use of plugins. (If testing is the only problem, I would gladly test it on Windows with mingw, and maybe Mac if needed)

Also, could you add in the documentation (cfe/trunk/docs/ClangPlugins.rst) what are the limitations/setup needed to make an out-of-tree plugin?


Repository:
  rL LLVM

http://reviews.llvm.org/D21385