[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