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@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@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
