Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Options in loadable modules are not available #1690

Closed
llvmbot opened this issue Apr 9, 2007 · 11 comments
Closed

Options in loadable modules are not available #1690

llvmbot opened this issue Apr 9, 2007 · 11 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead regression

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 9, 2007

Bugzilla Link 1318
Resolution FIXED
Resolved on Feb 22, 2010 12:47
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @xuzhongxing

Extended Description

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 9, 2007

assigned to @lattner

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 11, 2007

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 11, 2007

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?

@lattner
Copy link
Collaborator

lattner commented Apr 11, 2007

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.

@lattner
Copy link
Collaborator

lattner commented Apr 11, 2007

Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047219.html

sorry for the breakage!

-Chris

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 11, 2007

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.

@lattner
Copy link
Collaborator

lattner commented Apr 12, 2007

testing a fix.

@lattner
Copy link
Collaborator

lattner commented Apr 12, 2007

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 12, 2007

Thanks Chris!

@llvmbot
Copy link
Collaborator Author

llvmbot commented Nov 27, 2021

mentioned in issue llvm/llvm-bugzilla-archive#4849

@edwintorok
Copy link
Contributor

mentioned in issue llvm/llvm-bugzilla-archive#6669

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
[lldb/interpreter] Add REPL-specific init file
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead regression
Projects
None yet
Development

No branches or pull requests

3 participants