DavidSpickett wrote: Ok so it's not something in Windows itself, but as I understand it, the load address of a DLL is set by Windows. So when I read this:
> The post-run "target modules list" output orders the OS DLLs (ntdll, > kernel32, ...) by load address, which differs between the in-process debugger > and the lldb-server-on-Windows path. I am confused what "which" refers to. My first attempt to parse it is: The post-run "target modules list" output orders the OS DLLs (ntdll, kernel32, ...) by load address, **the load address** differs between the in-process debugger and the lldb-server-on-Windows path. But that doesn't seem right because lldb's actions shouldn't be changing where Windows decides to place the DLL. I think your intended meaning is: The post-run "target modules list" output orders the OS DLLs (ntdll, kernel32, ...) by load address, **the behaviour of "target modules list"** differs between the in-process debugger and the lldb-server-on-Windows path. So if that's the case, I wonder if there is need for a follow up. Whether: * `target modules list` should actually sort them by load address instead of relying on the server's response order, or - * lldb-server on Windows should use an ordered container and/or return a sorted response Though if we've never said we'd sort the list like this, let's not make any extra effort now. I doubt we have. Side note: I went looking for a rule to understand "which", and it seems entirely vibes based which I suppose is appropriate for current year. Mostly harmless but sometimes like here, it can be problematic. https://github.com/llvm/llvm-project/pull/203305 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
