Skip to content

[lldb][Docs] Document vFile:exists and vFile:MD5 #89357

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

[lldb][Docs] Document vFile:exists and vFile:MD5 #89357

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
518cb05
[lldb][Docs] Document vFile:exists and vFile:MD5
DavidSpickett Apr 19, 2024
b88a115
Wording
DavidSpickett Apr 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions lldb/docs/lldb-platform-packets.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@Awfa Awfa Apr 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// bits of the result, and finally the high 64 bits of the result. Both are in
// hex format 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.



Expand Down