[Lldb-commits] [lldb] [lldb][Windows] Relax dependent-modules-nodupe-windows OS-DLL ordering (PR #203305)

[David Spickett via lldb-commits]

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