labath wrote: Yeah, the thing which makes the core files different from live processes is that core files (at least minidumps, the situation is a bit fuzzier for elf cores) often have a better idea of where the files are located. OTOH, the dynamic loader plugin is a (I'm deliberately not using "the" because I could think of other places as well) for the thread-local storage lookup code, so we do the two to work together.
Regarding the "allow the DYLD to do it's own book keeping but just not handle loading/unloading modules owned by the CoreProcess" idea, how exactly would that differ from what your change in `DynamicLoaderPOSIXDYLD::DidAttach` does? In that the dynamic loader would not attempt to relocate the module if it has already been loaded by the process plugin, where as right now it does? I think that would make sense, though I also think that the current behavior (attempting to relocate it also does) -- my core question is: how likely is it that the dynamic loader will find the right thread-local for a module which was loaded by the process class, if the two classes can't even agree on its load address? https://github.com/llvm/llvm-project/pull/109477 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
