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[0].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;
             break;
----------------
Could you also document this packet in `docs/lldb-gdb-remote.txt`?


http://reviews.llvm.org/D16107



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to