This is related to bug 1317. When a loadable module is loaded its command line options are not available until the loaded module has been processed. This is a bit of a chicken-and-egg problem: 1. Option values aren't available until after ParseCommandLineOptions 2. A -load option doesn't get processed until after ParseCommandLineOptions 3. Options in the loaded module can't been seen by ParseCommandLineOptions 4. Unrecognized option errors are generated by ParseCommandLineOptions because the module hasn't been loaded yet. Consequently, you get errors about the names of optimization passes. I'm not sure how this ever worked or if its a result of the recent changes to CommandLine. There are several things we could do to rectify this: 1. Make a formal API for "foreign passes". That is, when we dlopen the shared object we look for a function of a particular name, add its address to a table of foreign passes, invoke that function to initialize, etc. This API could do many other things (like build a PassManager full of passes). 2. Incorporate the --load option into CommandLine. It would become a new type of option that contains a list of function addresses. The functions are obtained by dlopen/dlsym on the shared object. The function (in the shared object) is invoked to *properly* register any command line options. This implies that static option objects are not permitted in such objects. 3. We might want to add something to Support library that could be used (but not linked into) the loadable module. This would be an interface to make "LLVM compatible loadable modules" that takes care of many of the details. I.e. it provides a cleaner client side interface for the module writer. This lib would be linked into all tools that support --load.
Or 4. Preprocess all loads, removing them after processing them, then parsing the remaining commandline options. This would require the CommandLine library to call into the plugin loader, but that should be about it. This would also preserve the simplicity of moving passes into and out of the tree (rather than having to do new stuff for external passes). This bug is extremely serious for all external modules, as you cannot run a pass in an external module at all right now.
or even easier, refresh the option list after a load. This patch solves the problem: diff -r1.85 CommandLine.cpp 528a529,537 > > //If we saw a load option, special case that and reload our options > //Then we can process options registered by the load, so long as > //the load occurs before the options it registers > if (std::string(ArgName) == "load") { > PositionalOpts.clear(); > Opts.clear(); > GetOptionInfo(PositionalOpts, Opts); > } Any objections?
I'll take a look at this. There is nothing special here about the load command, I'll solve this a more general way. Working on it.
Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047219.html sorry for the breakage! -Chris
As of now, HEAD does not fix this: opt -load=Debug/lib/LLVMHello.so -hello2 opt: Unknown command line argument '-hello2'. Try: 'opt --help' Test case for this is now in test/Feature/load_module.ll Please make sure you update lib/Transforms/Makefile and build LLVMHello.so upon which this test case now depends.
testing a fix.
Fixed better, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047343.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047344.html Testcase here: test/Feature/load_module.ll -Chris
Thanks Chris!