================
@@ -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
----------------
DavidSpickett wrote:
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.
https://github.com/llvm/llvm-project/pull/89357
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
