[PATCH] D56237: Implement GetFileLoadAddress for the Windows process plugin

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

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.



================
Comment at: source/Plugins/Process/Windows/Common/ProcessWindows.cpp:878
+                  section_sp->GetFileAddress();
+      load_addr += module->GetObjectFile()->GetFileOffset();
+      break;
----------------
I think FileOffset will always be zero here. The only case where this is not zero is for fat macho binaries. And even in that case, I don't think adding that offset to the load address is the right thing to do.


================
Comment at: source/Plugins/Process/Windows/Common/ProcessWindows.cpp:886
+  }
+  return Status("Moudle is not loaded");
+}
----------------
typo


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D56237