Seems reasonable, I can add something to the help. What do you think about also changing the semantics of --clean to clear the module list regardless of if the modules are orphaned? I've spent the past 2 days trying to track down a refcounting bug related to the shared module list that only happens when running from the test suite, even if I run the exact same sequence of commands from inside LLDB. But the gist of it is that when running from the test suite, when RemoveOrphanSharedModules() is called from the CommandObject, the ModuleSP for the executable has a ref count of 2, so it isn't unique to the shared module list, and it doesn't get removed.
I tested to see what happens if I change this logic to remove from the module list regardless of whether it's unique, and I can't find any unintended side effects other than lots of tests start passing :) shared_ptrs are shared, so in theory there shouldn't be any negative consequences to just removing it. Whoever still has a reference can still continue to use it. Alternatively I can add a --force command line option, so that the semantics of specifying just --clean are unchanged. Thoughts? http://reviews.llvm.org/D8615 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
