[Lldb-commits] [PATCH] D134581: [lldb] Prevent re-adding a module that is already loaded

Alvin Wong via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 26 05:04:50 PDT 2022


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



More information about the lldb-commits mailing list