Hui added a comment.

In D56237#1344682 <https://reviews.llvm.org/D56237#1344682>, @labath wrote:

> I think there is something wrong here. Normally, it should be the job of the 
> dynamic loader plugin to figure out where a module got loaded (and populate 
> the target section load list). `Process::GetFileLoadAddress` is there to help 
> it with this job. So, the fact that `ProcessWindows::GetFileLoadAddress` goes 
> back to the target section load list to get the data creates a weird loop. 
> The only way I can see this working is if this implementation happens to 
> return the module base address, as specified in the object file, and that 
> base address happens to be correct (no ASLR). The kind of code I would expect 
> to see here is a call to some windows API to determine the load address 
> straight from the OS (if such a thing is possible). For example, on Linux, we 
> parse the `/proc/<pid>/maps` file to determine this information.


The Process::GetFileLoadAddress is needed for both process clients mentioned 
here. For the remote process, it will be the remote platform's responsibility 
to provide the load address. The remote platform could be lldb-server or other 
server eligible to connect to lldb.  Currently the processwindows plugin knows 
about the load address since the plugin is notified the process base address 
(or say the randomized image base) by windows debug event when the process is 
loaded on Windows. So the processwindows::GetFileLoadAddress actually does a 
job for dyld's convenience. Later on, if a native windows process is just a 
pass-through to processwindows, it will benefit the same feature (I am thinking 
processwindows is working as a common implementation for windows specific).

It is doable on windows to get the process base address by enumerate the 
process's module. I tried the following. The load address has the same result 
as processwindows::GetFileLoaddAddress().

+lldb::addr_t Host::GetProcessBaseAddress(lldb::pid_t pid) {
+  AutoHandle snapshot(CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, pid));
+  if (!snapshot.IsValid())
+    return LLDB_INVALID_ADDRESS;
+
+  MODULEENTRY32W me;
+  me.dwSize = sizeof(MODULEENTRY32W);
+  if (Module32FirstW(snapshot.get(), &me)) {
+    // The first module is always the EXE or DLL itself.
+    return (addr_t)me.modBaseAddr;
+  }
+
+  return LLDB_INVALID_ADDRESS;
+}
+


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56237/new/

https://reviews.llvm.org/D56237



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to