[lldb][Docs] Document vFile:exists and vFile:MD5 #89357
Conversation
These are extensions the lldb platform has to: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Host-I_002fO-Packets.html#Host-I_002fO-Packets
|
@llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) ChangesThese are extensions the lldb platform has to: Full diff: https://github.com/llvm/llvm-project/pull/89357.diff 1 Files Affected:
diff --git a/lldb/docs/lldb-platform-packets.txt b/lldb/docs/lldb-platform-packets.txt
index 4cf575e5ee8adb..fa6ec720c7ed42 100644
--- a/lldb/docs/lldb-platform-packets.txt
+++ b/lldb/docs/lldb-platform-packets.txt
@@ -429,7 +429,43 @@ incompatible with the flags that gdb specifies.
//
// Response is F, followed by the number of bytes written (base 16)
+//----------------------------------------------------------------------
+// vFile:MD5:
+//
+// BRIEF
+// Generate an MD5 hash of the file at the given path.
+//
+// EXAMPLE
+//
+// receive: vFile:MD5:2f746d702f61
+// send (success): F,00000000000000001111111111111111
+// send (failure): F,x
+//
+// request packet contains the ASCII hex encoded filename
+//
+// If the hash succeeded, the response is "F," followed by the low 64
+// bits of the result, then the high 64 bits of the result. Both are hex
+// without a prefix.
+//
+// The response is "F,", followed by "x" if the file did not exist
+// or failed to hash.
+//----------------------------------------------------------------------
+// vFile:exists:
+//
+// BRIEF
+// Check whether the file at the given path exists.
+//
+// EXAMPLE
+//
+// receive: vFile:exists:2f746d702f61
+// send (exists): F,1
+// send (does not exist): F,0
+//
+// request packet contains the ASCII hex encoded filename
+//
+// The response is a return code where 1 means the file exists
+// and 0 means it does not.
|
|
Ideally they'd be in some sort of order but they are already not, and I'm thinking it would be good to get these on the website anyway. So I'm leaving concerns like that until later. |
| // | ||
| // request packet contains the ASCII hex encoded filename | ||
| // | ||
| // If the hash succeeded, the response is "F," followed by the low 64 |
There was a problem hiding this comment.
As an aside does this mean that the hash as seen in the packet has the low and high 64 bits swapped from what would be displayed by e.g. the md5 command? For example e9800998ecf8427ed41d8cd98f00b204 for an empty file rather than d41d8cd98f00b204e9800998ecf8427e
There was a problem hiding this comment.
By the way, I remember observing that the hash that comes out from CalculateMD5 differed from the md5sum command before. Like entirely - not just the halves swapped. I didn't think any problem of it though - because it was consistent between client + server.
There was a problem hiding this comment.
We do:
auto Result = llvm::sys::fs::md5_contents(path);
Then if we look into that, I see:
uint64_t low() const {
// Our MD5 implementation returns the result in little endian, so the low
// word is first.
I guess that md5sum shows the result as a 128 bit number in the usual "big endian" style.
As to why the result might be entirely different, perhaps you were seeing the little endian difference but if not, no idea why. As you say if it's incorrect then it's been so for a long time.
|
I forgot I didn't land this, so I will instead push a Markdown version of the same content once the other PRs have landed. |
This is a Markdown version of #89357.
|
Landed as markdown in bd53c7c. |
These are extensions the lldb platform has to:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Host-I_002fO-Packets.html#Host-I_002fO-Packets