[Lldb-commits] [lldb] [lldb] Add target modules replace command (PR #214576)

[Greg Clayton via lldb-commits]

clayborg wrote:

> > @clayborg @jimingham, added a new commit that changes the `--force` flag and adds a new flag that replaces the old `force` flag.
> > ```
> > target modules replace [--old-path <path>] [--allow-uuid-mismatch] [--force] <path>
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Now unless its a placeholder, you always will use `force`, if you want to replace a module and UUID doesn't match we pass `--allow-uuid-mismatch` or `m`.
> 
> I haven't looked at the implementation in detail yet.
> 
> Under what circumstances would you want to use --force and --allow--uuid--mismatch? Those still don't seem safe to me. 


I think we just need a --force flag. Sometimes LLDB makes up its own UUID by creating some sort of debug info CRC if there is no GNU build ID. So this is the reason we need the --force. There are no UUID flavors in LLDB right now, something I would love to fix at some point. But if the current module has a debug info CRC of 1122334455 as the UUID and we find the right module somehow and want to replace it, that is when we would use the --force option.

> In any case, there should be more explanation of the trouble you might get into - stranded symbols or accidentally finding the module by UUID if another target is holding onto the original module.
> 
> There should also be some testing of the case where you can't discard the original Module because another target is holding onto a reference to it. Or if that case is really problematic, you'll need to find a way to outlaw it as well.

We are asking one target to replace a module, we shouldn't have to worry about other targets as they have a strong reference to their module and they can keep it. We could add a --global flag to the command to replace the module in all targets if that is really important. Any other targets will maintain their strong reference to their existing modules.

If we keep a copy of the old module around, just not in the global shared cache, we shouldn't have any major problems. 



https://github.com/llvm/llvm-project/pull/214576