This is an archive of the discontinued LLVM Phabricator instance.

Add a --all command option to "target delete"
Needs ReviewPublic

Authored by zturner on Mar 25 2015, 1:21 PM.

Details

Reviewers
jingham
Summary

Fairly self explanatory. The immediate use case for this is to add code to lldbtest teardown that deletes all targets before running make clean, to deal with file locking issues on Windows. But the option is generally useful independently of the test suite anyway.

I made the --all option not require an argument (so you just use --all instead of --all true). For consistency, I changed the --clean flag to work the same way by changing the last argument being passed to the constructor of m_clean_option from false to true. I don't think this is a big issue since we don't guarantee stability of the CLI and this is not a heavily used option, but worth calling out anyway.

Diff Detail

Event Timeline

zturner updated this revision to Diff 22670.Mar 25 2015, 1:21 PM
zturner retitled this revision from to Add a --all command option to "target delete".
zturner updated this object.
zturner edited the test plan for this revision. (Show Details)
zturner added a reviewer: jingham.
zturner added a subscriber: Unknown Object (MLST).
jingham edited edge metadata.Mar 25 2015, 2:38 PM

I think it is worth mentioning in the help that if you do "clean" then you will need to reparse all shared modules the next time you debug. This can be a significant hiccup when you next debug... Can't think of a succinct way to say this off the top of my head, though...

I try to use boolean values only when it isn't clear what the default value is (for instance if it is also controlled by a setting, or maybe situationally determined.) That's not true for --all or --clean so it is fine to have them be argument-less flags.

And while I would be concerned about changing commonly used CLI options since that will make aliases to fail, these are not common options, so it is okay to clean up the clean option.

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?

Ironically even though I've been staring at this problem for 2 days I think
I actually figured this out shortly after my last email.
TestBase.tearDown() already deletes all the targets but it was calling
Base.tearDown before doing TestBase.tearDown(). So the setup looked like
this:

def setup(self):

Base.setup(self)

# Do TestBase specific stuff

def tearDown(self):

Base.tearDown(self)

# Do TestBase specific stuff

the orders here need to be reversed to ensure that teardown happens in
reverse order from setup. In particular Base.tearDown() was calling the
tear down hooks, one of which in this case was to call make clean. So make
clean was being called before the targets were deleted. My clean --all
helped, but as you said, the SB stuff was still holding a reference
somewhere.

I fixed this by reversing the orders and also fixed about 20 other tests in
the process. Yay for progress.