DmT021 wrote: > I was chatting with Jim Ingham and he was a little bummed that we're looking > at doing this in a single DynamicLoader plugin, instead of having the > DynamicLoader plugin create a list of ModuleSpec's and having a central > method in ModuleList or something, create Modules for each of them via a > thread pool, and then the DynamicLoader plugin would set the section load > addresses in the Target, run any scripting resources (python in .dSYMs), call > ModulesDidLoad etc.
I'm looking at the implementation of `DynamicLoaderDarwin::FindTargetModuleForImageInfo` and to me it seems like moving the parallelization into a common place (let's say `Target::GetOrCreateImages`) would give us significant complexity. We can't just make a module_spec and call a method to load it for us, there should be either a complicated description of what to load or some kind of back-and-forth communication between `GetOrCreateImages` and a dynamic loader. For darwin: 1) create a module_spec 2) check if there's an image in the target images that matches it already 3) if it's not, and if we can use the shared cache, make a new module_spec and try to load a module with it 4) if it still fails, try to load it with the original module_spec 5) if it still fails, try to load it with `m_process->ReadModuleFromMemory`. https://github.com/llvm/llvm-project/pull/110439 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
