Piotr Rak
2014-Feb-19 22:54 UTC
[LLVMdev] VMRange merging in ProcessElfCore and DoReadMemory
Hi Todd, I am bit lost in code base and might be confused, but I think we are not getting ProcessElfCore::DoReadMemory still right. Your fix (rev 201214<http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp?r1=196125&r2=201214>) to llvm.org/PR18769 with not merging VMRange's regions if those are from other location in core file is correct. But when we are requested to do read at boundary of two such not merged VMRanges, we will read correct data from from file to the end of 'last_entry->data.GetRangeEnd()' and then we fill rest with '\0'. I think that we should split our requested read operation, to all such ranges in this case. Is that correct? I initially thought it was the problem I am after, since I am able to still reproduce this issue for some dumps (mainly multithreaded ones), but I haven't nailed it down to this case. However it is still my belief that there is (at least potential) issue there. I will be able provide this fix during the weekend, given my analysis is correct, but for now I wanted to focus on my original issue - which for now leads to ModuleList not being preserved for some reason once created in DynamicLoaderPOSIXDYLD::DidLaunch for core files. Yet it is still my guess and I need to play with bit more. Cheers, /Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140219/ffa34fdd/attachment.html>
Todd Fiala
2014-Feb-19 23:16 UTC
[LLVMdev] VMRange merging in ProcessElfCore and DoReadMemory
[Moving LLVM to BCC and adding lldb-dev] Hi Piotr! Thanks for the note. On Wed, Feb 19, 2014 at 2:54 PM, Piotr Rak <piotr.rak at gmail.com> wrote:> But when we are requested to do read at boundary of two such not merged > VMRanges, we will read correct data from from file to the end of > 'last_entry->data.GetRangeEnd()' and then we fill rest with '\0'. > I think that we should split our requested read operation, to all such > ranges in this case. > > Is that correct? > >For the elf core file support, each of those memory regions represent a memory segment of the elf file. I don't *think* you should be having any memory objects which span across segments. So while it might be true that a request for a contiguous range of VM memory starts off in one segment's VM map entry and might zero fill if it would cover multiple segments that were not merged, I'm not sure what would be driving the need to do that. What is the scenario where the need to read memory over multiple segments is showing up? If we did need to do it, I think you are right in that we'd need to merge reads from each of the VM regions that overlapped with the read request. Let me know what you find! Thanks, Todd -- Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140219/cc9a018c/attachment.html>