[Lldb-commits] [lldb] r156994 - /lldb/trunk/source/Host/common/Host.cpp
jingham at apple.com
Fri May 18 12:51:41 PDT 2012
Targets belong to debuggers so I think it makes sense for the dummy target to belong to the Debugger passed into GetDummyTarget. So when you start a new debug session (i.e. make a new Debugger) then you'll get a new DummyTarget appropriate to that Debugger. And if you call "SetDefaultArchitecture" on the debugger, it should dump the dummy target if it exists, so that the next request for it will make it with the correct architecture.
On May 18, 2012, at 10:31 AM, Filipe Cabecinhas <filcab at filcab.net> wrote:
> But how would that avoid using the cached dummy target after it's destroyed?
> The problem is this: (lldbtest.py:TestBase.tearDown()):
> # Delete the target(s) from the debugger as a general cleanup step.
> # This includes terminating the process for each target, if any.
> # We'd like to reuse the debugger for our next test without incurring
> # the initialization overhead.
> targets = 
> for target in self.dbg:
> if target:
> process = target.GetProcess()
> if process:
> rc = self.invoke(process, "Kill")
> self.assertTrue(rc.Success(), PROCESS_KILLED)
> for target in targets:
> What we can do is:
> Restore the method as it was before, but add a check for g_dummy_target_sp->IsValid()
> Implement the Target::IsValid() method that would, for example, check a m_valid boolean that would be set to false on Destroy().
> What do you think?
> On Friday, May 18, 2012 at 6:11 PM, Greg Clayton wrote:
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
More information about the lldb-commits