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

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Jan 3 02:00:17 PST 2019

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");




More information about the lldb-commits mailing list