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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
