[Lldb-commits] [PATCH] D16107: Fix for Bug 25338
Pavel Labath via lldb-commits
lldb-commits at lists.llvm.org
Tue Jan 12 04:11:30 PST 2016
labath added a comment.
Could you explain what is the nature of the failure in the vdso parsing? Otherwise it's quite hard to see what's the relationship of your patch to it, as it seems that the ObjectFile should be able to handle files which are not fully contained within the initial read (comment on Module::GetMemoryObjectFile says that it's enough if size_to_read contains the file header).
Also, if this fixes a test (I think I remember us disabling a test because of this), can you please enable it again?
Comment at: include/lldb/Target/Process.h:3145
@@ +3144,3 @@
+ /// Try to find the end address of a file.
+ /// The end address is defined as the address of the last memory
+ /// region what contains data mapped from the specified file.
This definition sounds confusing to me. I would read this as the "start address of the last block ...", which is clearly not what you want. It's probably enough to change it to "*end* address of the last block".
Comment at: source/Plugins/Process/Linux/NativeProcessLinux.cpp:2973
@@ +2972,3 @@
+ StringExtractor addr_extractor(maps_columns.str().c_str());
+ addr_extractor.GetHexMaxU64(false, LLDB_INVALID_ADDRESS);
+ char ch = addr_extractor.GetChar('\0');
This will be wrong if the file contains multiple entries for the same file (probably because different segments are mapped with different permissions). Doesn't happen for the vdso, but all other files have this. You should probably look for the *last* segment matching this file and get it's end address.
Comment at: source/Utility/StringExtractorGDBRemote.cpp:149
@@ -148,2 +148,3 @@
if (PACKET_STARTS_WITH ("qFileLoadAddress:")) return eServerPacketType_qFileLoadAddress;
+ if (PACKET_STARTS_WITH ("qFileEndAddress:")) return eServerPacketType_qFileEndAddress;
Could you also document this packet in `docs/lldb-gdb-remote.txt`?
More information about the lldb-commits