[lldb-dev] does vFile:Open actually work?

[Jason Molenda via lldb-dev]

Yeah, this is a bug in lldb's implementation of vFile:open.  lldb talks to lldb-server (in platform mode) so it will work with itself, but it will not interoperate with any other implementations.  That's the down side to having the client and server literally built from the same sources. :) 


I have a small self-contained platform implementation I wrote locally from the specification, and I stumbled across the bug last winter.  We'll need to add a packet so lldb can request standards-correct vFile:open: behavior, and fall back to its original implementation if it that is not understood for a while so we interoperate with existing platforms in the wild.

A similar type of bug is lldb's incorrect implementation of the A packet, see https://bugs.llvm.org/show_bug.cgi?id=42471 - Spencer had the good suggestion of creating a protocol fixes packet to query for these so additional ones can be added in the future, he suggested:


> Request: "qProtocolFixes:fix;…" where each 'fix' is one of the following strings:
>   - "GDBFlagsInvFileOpen"
>   - "GDBBaseInAPacket"
>   - ...
> Unknown strings are acceptable, but ignored. If a fix  string is not present, it is assumed that that fix is not present.
> 
> Response: "fix;…", same definition as 'fix' above.


I have a little TODO on myself to do this (<rdar://problem/46788934>).



J



> On Oct 10, 2019, at 2:39 PM, Larry D'Anna via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> The comments in File.h say:
> 
>   // NB this enum is used in the lldb platform gdb-remote packet
>   // vFile:open: and existing values cannot be modified.
>   enum OpenOptions {
>     eOpenOptionRead = (1u << 0),  // Open file for reading
>     eOpenOptionWrite = (1u << 1), // Open file for writing
>     eOpenOptionAppend =
>         (1u << 2), // Don't truncate file when opening, append to end of file
> 
> And In GDBRemoteCommunicationServerCommon.cpp it says:
> 
>       uint32_t flags = packet.GetHexMaxU32(false, 0);
>       if (packet.GetChar() == ',') {
>         mode_t mode = packet.GetHexMaxU32(false, 0600);
>         FileSpec path_spec(path);
>         FileSystem::Instance().Resolve(path_spec);
>         // Do not close fd.
>         auto file = FileSystem::Instance().Open(path_spec, flags, mode, false);
> 
> 
> But in the GDB documentation it says:
> 
> @node Open Flags
> @unnumberedsubsubsec Open Flags
> @cindex open flags, in file-i/o protocol
> 
> All values are given in hexadecimal representation.
> 
> @smallexample
>   O_RDONLY        0x0
>   O_WRONLY        0x1
>   O_RDWR          0x2
>   O_APPEND        0x8
>   O_CREAT       0x200
>   O_TRUNC       0x400
>   O_EXCL        0x800
> @end smallexample
> 
> 
> Does vFile:Open actually work?  Are there any tests that cover it?
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev