alvinhochun added a comment. In D134581#3813757 <https://reviews.llvm.org/D134581#3813757>, @alvinhochun wrote:
> In D134581#3813484 <https://reviews.llvm.org/D134581#3813484>, @jasonmolenda > wrote: > >> I probably misunderstand the situation DynamicLoaderWindows finds itself in, >> but in DynamicLoaderDarwin we have similar behavior - you run 'lldb binary' >> and lldb loads all the directly linked dynamic libraries into the target it >> creates, pre-execution. When execution starts, the dynamic linker tells us >> where the binary is loaded in memory and we call Target::SetExecutableModule >> with it. Target::SetExecutableModule has a side effect of clearing the >> Target's module list - you now have only one binary in the Target, your >> executable module. (this is done so the 0th image in the image list is your >> executable module) >> >> Why aren't your pre-loaded DLLs unloaded when you call >> Target::SetExecutableModule? > > In `ProcessWindows::OnDebuggerConnected`, it first checks > `GetTarget().GetExecutableModule()`. Only when the returned module is null > (i.e. the binary hasn't already been loaded) then it calls > `GetTarget().SetExecutableModule(module, eLoadDependentsNo)`. If I understood > you correctly, then the right thing to do there should be to call > `GetTarget().SetExecutableModule(module, eLoadDependentsNo)` in all cases, > without checking `GetExecutableModule`, right? > > It seems to make sense, but I may need some comments from other reviewers on > this. I made a follow-up patch D134636 <https://reviews.llvm.org/D134636> for this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134581/new/ https://reviews.llvm.org/D134581 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
