The difference between SBTarget Clear and Destroy?

Hello,

I could not find it in the docs, so I am asking here:

Assuming that I have an instance of type SBTarget:

SBTraget target;

Whats the difference between calling:

target.Clear()

and

lldb::SBDebugger::Destroy( &target ) ?

Thanks,

Sorry, meant the difference between:

target.Clear() and debugger.DeleteTarget( &target );

Thanks

Clear just releases the shared pointer to the target that you have. So in your IDE, when you are done with a target, you can call clear to ensure that your IDE isn't the only thing holding onto the target and keeping it and all shared libraries in memory:

void
SBTarget::Clear ()
{
    m_opaque_sp.reset();
}

Delete target will call "Target::Destroy()" which will kill the process if it is still around, and also clear the target's image list, then it will remove any shared libraries from the global shared library cache in LLDB that were only referenced by the target you were destroying:

bool
SBDebugger::DeleteTarget (lldb::SBTarget &target)
{
    bool result = false;
    if (m_opaque_sp)
    {
        TargetSP target_sp(target.GetSP());
        if (target_sp)
        {
            // No need to lock, the target list is thread safe
            result = m_opaque_sp->GetTargetList().DeleteTarget (target_sp);
            target_sp->Destroy();
            target.Clear();
            const bool mandatory = true;
            ModuleList::RemoveOrphanSharedModules(mandatory);
        }
    }
...

So this is a great way for an IDE, which might have one or more debug windows open, to reclaim the memory that was solely associated with a given target.

LLDB permanently caches the shared libraries that it loads in a global cache so the next time you debug, we have all those shared libraries instantly loaded and ready for you to use. This can greatly increase your restart performance, so don't call SBDebugger::DeleteTarget() if you are going to immediately debug again using the same target. Try and keep the existing target around for all of your runs of that process so the module cache works in your favor.

Thanks for the clarification!

Eran