[lldb] Remote disk file/directory completion for platform commands

[MrHate]

Summary

1. Extended the gdb-remote communication related classes with disk file/directory completion functions;
2. Added two common completion functions RemoteDiskFiles and RemoteDiskDirectories based on the functions above;
3. Added completion for these commands:
   1. platform get-file <remote-file> <local-file>;
   2. platform put-file <local-file> <remote-file>;
   3. platform get-size <remote-file>;
   4. platform settings -w <remote-dir>;
   5. platform open file <remote-file>.
4. Added related tests for client and server;
5. Updated docs/lldb-platform-packets.txt.

[teemperor]

The generic command part seems fine, but I'm not familiar enough with the GDB remote code to review that. Pavel and Jonas should know this better. Also + Jason and Greg.

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

2989

I think this breaks for paths that have a comma in them?

[MrHate]

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

2989

I think so. It might be better if I put the hex32 value before the comma.

[MrHate]

1. Corrected summary;
2. Added a test case for client which provides mock response for autocomplete request and test completion on command line;
3. Modified the argument order of the autocomplete request packet replacing vFile:autocomplete:<partial_path>,<only_dir> with vFile:autocomplete:<only_dir>,<partial_path>, so commas won't break partial path resolving.

[MrHate]

• Added a server test.

[jasonmolenda]

This is mostly fine. You need to escape the completed filenames you send back. You should have a test case where multiple matches are returned, like "a" matches "abc1" and "abc2".

I'm not too convinced that adding this packet as a vFile: is the right approach, although I understand why you went that way. All of the existing vFile: packets are direct overlays with POSIX low level APIs - open, close, unlink, chmod, read, write, etc. This is an entirely different thing, even though it works with files. I would personally write this as a Q packet -- a lot of lldb extensions to gdb Remote Serial Protocol end up as Q packets. QFilenameCompletion or something. You can keep the same packet design - that's fine. With more complex packets we're starting to use JSON more often these days, but this is simple and I think you've got the right idea.

You should definitely update docs/lldb-platform-packets.txt as part of your patch. I wrote a standalone platform implementation a while back, and tried to document all of the packets involved in this.

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

737

We only return 8-byte error code and we try to pick a different number for each error return so you could track down WHICH error condition was being hit for each Enn received (by looking at the source). Of course, given that each packet has a unique set of error returns possible, it was unnecessary to have a completely unique number across all packets -- you only need to disambiguate between different error responses to this one packet.

There's also a newer extended error mechanism where error strings can be returned, but I don't see that being helpful here.

752

This will include a , character before the first matched filename if there are more than one.

753

You'll need to use asciihex-encoded strings in the response - that's not being done, right? If a filename has a #, }, or $ in the string anywhere, it will be the end of the debug session.

[MrHate]

1. Renamed all "vFile:autocomplete" related into "qDiskAutocomplete";
2. Refactored match response from "[cstr],[cstr]..." into "[length]:[str bytes][length]:[str bytes]...";
3. Updated docs/lldb-platform-packets.txt;
4. Use 85 as the server's response error code.

Thanks for the suggestions!

[MrHate]

• Extended the server test into 3 separated cases:
  1. disk file with 1 match and 2 matches;
  2. disk dir on non-windows platform (for '/');
  3. disk dir on windows (for '\').

[jasonmolenda]

Nice set of changes, and you're right it should be a lower-case "q" packet, not an upper-case "Q" packet like I suggested, it's just querying information from the remote side.

In the response, I would not specify the length of the filenames, it's unnecessary. This can be something simply like,

bool first = true;
for (const auto &match : matches) {
  if (first) {
    first = false;
  } else {
    response.PutChar(',');
  }
  response.PutStringAsRawHex8(match.c_str());
}

(or however you want to add the commas after the first one, that's not the important part)

This is a pretty common design for gdb remote serial protocol packets IMO.

[labath]

Yeah, this looks very good. In particular, I like how you've separated the tests for the client and server-side implementations. Some comments inline.

In D85284#2209025, @jasonmolenda wrote:

Nice set of changes, and you're right it should be a lower-case "q" packet, not an upper-case "Q" packet like I suggested, it's just querying information from the remote side.

In the response, I would not specify the length of the filenames, it's unnecessary. This can be something simply like,

bool first = true;
for (const auto &match : matches) {
  if (first) {
    first = false;
  } else {
    response.PutChar(',');
  }
  response.PutStringAsRawHex8(match.c_str());
}

(or however you want to add the commas after the first one, that's not the important part)

This is a pretty common design for gdb remote serial protocol packets IMO.

+1 for length-less comma-separated hex-encoded file names.

lldb/docs/lldb-platform-packets.txt

241 ↗

(On Diff #284568)

I find myself not liking the word "Disk" in the packet name. I get that that's the name of the underlying api, but I'm not terribly fond of that either (and unlike the internal api, changing the packet name is not that easy). I'd rather go with something like qFilenameComplete like Jason suggested, as that does not imply any particular storage medium.

254 ↗

(On Diff #284568)

This should be cleared up more. It's not clear whether "true" means completing files or directories. And IIUC, completing directories are also included when completing files, but that is not obvious from the description.

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

94

This will make the command also available to the LLGS (gdb-server) personality of lldb-server. Do we want that? If not, we should put this in GDBRemoteCommunicationServerPlatform.

lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py

287–289

This is not likely to be useful in other tests. It'd be better to return an error here and provide an actual implementation in the test file. That will make it clear why does the test expect a particular string to be completed.

lldb/test/API/tools/lldb-server/TestGdbRemoteCompletion.py

64

what exactly is the expectation regarding the trailing directory separator? Should it be added only for directory completions or also for file completions if the completed thing happens to be a directory? This should be documented in the packet description.

Incidentally, I don't think it's useful to create a whole new test just to differentiate between the directory separator. You could just check the host platform in the test and adjust the expectation based on that.

[MrHate]

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

94

Yes, this is a platform dedicated feature.

And may I ask about how to create a lldb-server platform dedicated test? It seems the lldb-server test suite is mainly aimed at llgs and debugserver. I dont really understand what the debugserver is, and now it's not suitable for a llgs test.

[labath]

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

94

We don't currently have a good mechanism to write platform dedicated tests. The platform features are tested implicitly when running the test suite remotely, and we have one or two tests (TestPlatformProcessConnect) which also spawn platform instances manually (but only when running remotely).

That said, I don't think it should be too difficult to add a method for testing the platform features directly. I think all it would take is to write a new function similar to connect_to_debug_monitor which would run the platform instance and connect to it. After that, all of the usual test methods should work, because they are essentially speaking the same protocol. I think the launch sequence could roughly be:

port_file = self.getBuildArtifact("port")
server = self.spawnSubprocess(get_lldb_server_exe(), ["platform", "--listen", "*:0", "--socket-file", port_file)
port = lldbutil.wait_for_file_on_target(port_file)
# connect to port and start communicating

[MrHate]

1. Renamed packet related into "qPathComplete";
2. Refactored response form into comma-separated;
3. Moved the functions from GDBRemoteCommunicationServerCommon to GDBRemoteCommunicationServerPlatform;
4. Refactored the server-side test into lldb-platform dedicated, combined test cases into just one;
5. Now MockGDBServerResponder.qPathComplete responses with just an empty string.

My sincerest appreciation for all these suggestions/comments.

Now the server test works well except that the lldb-server subprocess cannot be terminated gracefully due to a TypeError thrown by sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET) in shutdown_socket, the backtrace is

Traceback (most recent call last):
  File "/home/ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 349, in shutdown_socket
    sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET)
TypeError: a bytes-like object is required, not 'str'

[MrHate]

• Updated the packet doc.

[labath]

In D85284#2216311, @MrHate wrote:

Now the server test works well except that the lldb-server subprocess cannot be terminated gracefully due to a TypeError thrown by sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET) in shutdown_socket, the backtrace is

Traceback (most recent call last):
  File "/home/ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 349, in shutdown_socket
    sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET)
TypeError: a bytes-like object is required, not 'str'

Interesting. This isn't really related to your patch, is it (like, I would expect all gdb-remote tests to suffer from this python3 incompatibility)? I'll try to take a look at this later today, but if the test comes out as successful I don't think you have to wait for that. The patch looks good to me, aside from some small clarifications in inline comments.

lldb/docs/lldb-platform-packets.txt

254 ↗

(On Diff #284568)

I still don't find this very clear. I was expecting some text like:

If the first argument is zero, the result should contain all files (including directories) starting with the given path. If the argument is one, the result should contain only directories.
The result should be a comma-separated list of hex-encoded paths. Paths denoting a directory should end with a directory separator ('/' or '\').

However, I'm not sure if it accurately describes the interface. If it does, feel free to reuse the text. What I'd like to achieve is include enough information so that it is possible to reimplement this packet without consulting the lldb source code.

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp

360 ↗

(On Diff #285441)

I just realized that in case the completion returns no answers, this will return an empty packet. In gdb-remote parlance, an empty packet normally means "unimplemented". Now this is not normally going to cause an issue, since the only reasonable response to an unimplemented packet is to do no completion.

However, I think it would be more idiomatic to send an error response in this case. @jasonmolenda, would you agree?

361–364 ↗

(On Diff #285441)

You don't have to use this, but I figured I'd note that a usually cleaner way of skipping the first separator is:

StringRef separator;
for(...) {
  response << separator;
  separator = ",";
  ...
}

369–370 ↗

(On Diff #285441)

delete

lldb/test/API/tools/lldb-server/TestGdbRemoteCompletion.py

36–38

I'd consider doing something like:

encode = gdbremote_hex_encode_string
self.test_sequence.add_log_lines(
            ["read packet: $qPathComplete:0,%s#00"%encode("main"),
             ...

[labath]

In D85284#2217705, @labath wrote:

In D85284#2216311, @MrHate wrote:

Now the server test works well except that the lldb-server subprocess cannot be terminated gracefully due to a TypeError thrown by sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET) in shutdown_socket, the backtrace is

Traceback (most recent call last):
  File "/home/ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 349, in shutdown_socket
    sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET)
TypeError: a bytes-like object is required, not 'str'

Interesting. This isn't really related to your patch, is it (like, I would expect all gdb-remote tests to suffer from this python3 incompatibility)? I'll try to take a look at this later today, but if the test comes out as successful I don't think you have to wait for that. The patch looks good to me, aside from some small clarifications in inline comments.

That should be fixed by e6b1b61054.

[MrHate]

In D85284#2217862, @labath wrote:

In D85284#2217705, @labath wrote:

In D85284#2216311, @MrHate wrote:

Now the server test works well except that the lldb-server subprocess cannot be terminated gracefully due to a TypeError thrown by sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET) in shutdown_socket, the backtrace is

Traceback (most recent call last):
  File "/home/ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 349, in shutdown_socket
    sock.sendall(GdbRemoteTestCaseBase._GDBREMOTE_KILL_PACKET)
TypeError: a bytes-like object is required, not 'str'

Interesting. This isn't really related to your patch, is it (like, I would expect all gdb-remote tests to suffer from this python3 incompatibility)? I'll try to take a look at this later today, but if the test comes out as successful I don't think you have to wait for that. The patch looks good to me, aside from some small clarifications in inline comments.

That should be fixed by e6b1b61054.

Thanks very much.

The TypeError problem is solved, but the lldb-platform still complains about SIGHUP. lldb-platform aborts for SIGHUP, so I still get error messages from the lldb-platform subprocess when test ends. It seems the kill packet works well for lldb-gdbserver, but I don't know if it works for lldb-platform as well.

Now it looks like this:

Session logs for test failures/errors/unexpected successes will go into directory '/home/ubuntu/llvm-project/build/lldb-test-traces'
SIGHUP received, exiting lldb-server...
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/ubuntu/llvm-project/build/bin/lldb-server platform --listen *:0 --socket-file /tmp/tmpmyxqrfw8 
1.      Program arguments: /home/ubuntu/llvm-project/build/bin/lldb-server platform --listen *:0 --socket-file /tmp/tmpmyxqrfw8 
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4349e4]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4329ee]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x434f85]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7f8de017c8a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f8dde5d5f47]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f8dde5d78b1]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x41a19c]
/lib/x86_64-linux-gnu/libc.so.6(+0x3efd0)[0x7f8dde5d5fd0]
/lib/x86_64-linux-gnu/libpthread.so.0(send+0x1a)[0x7f8de017b97a]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4925a0]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x49936b]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4f69b2]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4ea43a]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4ea386]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4cd905]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x419e65]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x41b363]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f8dde5b8b97]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x415aca]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4349e4]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x432a25]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x434f85]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7f8de017c8a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f8dde5d5f47]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f8dde5d78b1]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x41a19c]
/lib/x86_64-linux-gnu/libc.so.6(+0x3efd0)[0x7f8dde5d5fd0]
/lib/x86_64-linux-gnu/libpthread.so.0(send+0x1a)[0x7f8de017b97a]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4925a0]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x49936b]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4f69b2]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4ea43a]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4ea386]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x4cd905]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x419e65]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x41b363]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f8dde5b8b97]
/home/ubuntu/llvm-project/build/bin/lldb-server[0x415aca]
PASS: LLDB (/home/ubuntu/llvm-project/build/bin/clang-x86_64) :: test_autocomplete_path (TestGdbRemoteCompletion.GdbRemoteCompletionTestCase)
----------------------------------------------------------------------
Ran 1 test in 0.283s

[MrHate]

1. Removed the unnecessary print line in GDBRemoteCommunicationServerPlatform.cpp;
2. Updated the packet doc;
3. Refactored the for-loop at line 359-364 in GDBRemoteCommunicationServerPlatform.cpp;
4. Refactored the server-side test with str.encode().hex().

If we need to response for qPathComplete with empty match result. I think we could provide a char like R or what as the response. The match result is encoded into hex-bytes, so it might be easy to resolve the error symbol from the result IMHO.

[jasonmolenda]

In D85284#2219603, @MrHate wrote:

1. Removed the unnecessary print line in GDBRemoteCommunicationServerPlatform.cpp;
2. Updated the packet doc;
3. Refactored the for-loop at line 359-364 in GDBRemoteCommunicationServerPlatform.cpp;
4. Refactored the server-side test with str.encode().hex().

If we need to response for qPathComplete with empty match result. I think we could provide a char like R or what as the response. The match result is encoded into hex-bytes, so it might be easy to resolve the error symbol from the result IMHO.

What if the response is "matches:<ASCIIHEX>[,<ASCIIHEX>]" and if there are no matches, just "matches:"? We don't want to send an empty string because that means "packet not known" in the remote serial protocol.

[MrHate]

In D85284#2219639, @jasonmolenda wrote:

In D85284#2219603, @MrHate wrote:

1. Removed the unnecessary print line in GDBRemoteCommunicationServerPlatform.cpp;
2. Updated the packet doc;
3. Refactored the for-loop at line 359-364 in GDBRemoteCommunicationServerPlatform.cpp;
4. Refactored the server-side test with str.encode().hex().

If we need to response for qPathComplete with empty match result. I think we could provide a char like R or what as the response. The match result is encoded into hex-bytes, so it might be easy to resolve the error symbol from the result IMHO.

What if the response is "matches:<ASCIIHEX>[,<ASCIIHEX>]" and if there are no matches, just "matches:"? We don't want to send an empty string because that means "packet not known" in the remote serial protocol.

"matches:" takes up 8 chars, maybe we can just use a 'M' as vFile:size uses 'F', so it may look like: "M<ASCIIHEX>[,<ASCIIHEX>]". What do you think?

[jasonmolenda]

In D85284#2219805, @MrHate wrote:

In D85284#2219639, @jasonmolenda wrote:

In D85284#2219603, @MrHate wrote:

1. Removed the unnecessary print line in GDBRemoteCommunicationServerPlatform.cpp;
2. Updated the packet doc;
3. Refactored the for-loop at line 359-364 in GDBRemoteCommunicationServerPlatform.cpp;
4. Refactored the server-side test with str.encode().hex().

If we need to response for qPathComplete with empty match result. I think we could provide a char like R or what as the response. The match result is encoded into hex-bytes, so it might be easy to resolve the error symbol from the result IMHO.

What if the response is "matches:<ASCIIHEX>[,<ASCIIHEX>]" and if there are no matches, just "matches:"? We don't want to send an empty string because that means "packet not known" in the remote serial protocol.

"matches:" takes up 8 chars, maybe we can just use a 'M' as vFile:size uses 'F', so it may look like: "M<ASCIIHEX>[,<ASCIIHEX>]". What do you think?

I don't have a real preference, but fwiw packet size basically doesn't effect performance over modern media (Bluetooth, WiFi, USB, TCP) - sending and receiving packets are expensive but extra bytes don't generally matter unless you're doing a large data transfer.

[MrHate]

• Added an 'M' at the beginning of the response packet, updated related doc and tests.

[labath]

I looked at the gdb-remote docs, and I could find precedents for both returning error (or OK) for "empty" responses, and prefixing the responses with a random character. So I think adding the M character is fine too.

I tried out the lldb-server test, and I ran into some problems -- see inline comments. I wouldn't be too worried about the SIGHUP thing. lldb-server process terminates correctly when the test closes the connection, but it test suite is too quick to follow that up with a SIGHUP, which throws it for a spin. The fix for that would be fairly simple if we were on python 3 (popen as a wait() method with a timeout), but given that we're not on py3 just yet, we can leave this cleanup to a slightly later date...

lldb/test/API/tools/lldb-server/TestGdbRemoteCompletion.py

38

This check fails for me because I have a main.cpp~ in addition to main.cpp (I have edited that file some time in the last two years). Similar can happen with other checks too.

I think it would be much safer to create an appropriate directory structure in the build folder and test completion on that. The build folder is erased before each test, so you can be sure it contains only things you created (in addition to make outputs).

43–50

This fails for me because the files end up in the opposite order. We could either sort the files in the test or in the actual implementation of the completion function.

[MrHate]

1. Now the server uses std::sort to sort the match result before writing into the response packet;
2. Refactored the server-side test to run within the build directory.

[labath]

Sorry about the delay. This looks good to me now.

lldb/include/lldb/Interpreter/CommandCompletions.h

enum CommonCompletionTypes {
     eModuleCompletion = (1u << 4),
     eSettingsNameCompletion = (1u << 5),
     ePlatformPluginCompletion = (1u << 6),
     eArchitectureCompletion = (1u << 7),
     eVariablePathCompletion = (1u << 8),
     eRegisterCompletion = (1u << 9),
     eBreakpointCompletion = (1u << 10),
     eProcessPluginCompletion = (1u << 11),
+    eRemoteDiskFileCompletion = (1u << 12),
+    eRemoteDiskDirectoryCompletion = (1u << 13),
     // This item serves two purposes.  It is the last element in the enum, so
     // you can add custom enums starting from here in your Option class. Also
     // if you & in this bit the base code will not process the option.
-    eCustomCompletion = (1u << 12)
+    eCustomCompletion = (1u << 14)
   };
 
   static bool InvokeCommonCompletionCallbacks(
       CommandInterpreter &interpreter, uint32_t completion_mask,
       lldb_private::CompletionRequest &request, SearchFilter *searcher);
 
   // These are the generic completer functions:
   static void DiskFiles(CommandInterpreter &interpreter,
                         CompletionRequest &request, SearchFilter *searcher);
 
   static void DiskFiles(const llvm::Twine &partial_file_name,
                         StringList &matches, TildeExpressionResolver &Resolver);
 
   static void DiskDirectories(CommandInterpreter &interpreter,
                               CompletionRequest &request,
                               SearchFilter *searcher);
 
   static void DiskDirectories(const llvm::Twine &partial_file_name,
                               StringList &matches,
                               TildeExpressionResolver &Resolver);
 
+  static void RemoteDiskFiles(CommandInterpreter &interpreter,
+                              CompletionRequest &request,
+                              SearchFilter *searcher);
+
+  static void RemoteDiskDirectories(CommandInterpreter &interpreter,
+                                    CompletionRequest &request,
+                                    SearchFilter *searcher);
+
   static void SourceFiles(CommandInterpreter &interpreter,
                           CompletionRequest &request, SearchFilter *searcher);
 
   static void Modules(CommandInterpreter &interpreter,
                       CompletionRequest &request, SearchFilter *searcher);
 
   static void Symbols(CommandInterpreter &interpreter,
                       CompletionRequest &request, SearchFilter *searcher);

lldb/include/lldb/Target/Platform.h

public:
   }
 
   virtual bool CloseFile(lldb::user_id_t fd, Status &error) { return false; }
 
   virtual lldb::user_id_t GetFileSize(const FileSpec &file_spec) {
     return UINT64_MAX;
   }
 
+  virtual void AutoCompleteDiskFileOrDirectory(CompletionRequest &request,
+                                               bool only_dir) {}
+
   virtual uint64_t ReadFile(lldb::user_id_t fd, uint64_t offset, void *dst,
                             uint64_t dst_len, Status &error) {
     error.SetErrorStringWithFormat(
         "Platform::ReadFile() is not supported in the %s platform",
         GetName().GetCString());
     return -1;
   }
 

lldb/include/lldb/Utility/StringExtractorGDBRemote.h

enum ServerPacketType {
     eServerPacketType_vFile_pwrite,
     eServerPacketType_vFile_size,
     eServerPacketType_vFile_mode,
     eServerPacketType_vFile_exists,
     eServerPacketType_vFile_md5,
     eServerPacketType_vFile_stat,
     eServerPacketType_vFile_symlink,
     eServerPacketType_vFile_unlink,
+    eServerPacketType_vFile_autocomplete,
     // debug server packages
     eServerPacketType_QEnvironmentHexEncoded,
     eServerPacketType_QListThreadsInStopReply,
     eServerPacketType_QPassSignals,
     eServerPacketType_QRestoreRegisterState,
     eServerPacketType_QSaveRegisterState,
     eServerPacketType_QSetLogging,
     eServerPacketType_QSetMaxPacketSize,

lldb/source/Commands/CommandCompletions.cpp

const CommonCompletionElement common_completions[] = {
       {eModuleCompletion, CommandCompletions::Modules},
       {eSettingsNameCompletion, CommandCompletions::SettingsNames},
       {ePlatformPluginCompletion, CommandCompletions::PlatformPluginNames},
       {eArchitectureCompletion, CommandCompletions::ArchitectureNames},
       {eVariablePathCompletion, CommandCompletions::VariablePath},
       {eRegisterCompletion, CommandCompletions::Registers},
       {eBreakpointCompletion, CommandCompletions::Breakpoints},
       {eProcessPluginCompletion, CommandCompletions::ProcessPluginNames},
+      {eRemoteDiskFileCompletion, CommandCompletions::RemoteDiskFiles},
+      {eRemoteDiskDirectoryCompletion,
+       CommandCompletions::RemoteDiskDirectories},
       {eNoCompletion, nullptr} // This one has to be last in the list.
   };
 
   for (int i = 0;; i++) {
     if (common_completions[i].type == eNoCompletion)
       break;
     else if ((common_completions[i].type & completion_mask) ==
                  common_completions[i].type &&

 }
 
 void CommandCompletions::DiskDirectories(const llvm::Twine &partial_file_name,
                                          StringList &matches,
                                          TildeExpressionResolver &Resolver) {
   DiskFilesOrDirectories(partial_file_name, true, matches, Resolver);
 }
 
+void CommandCompletions::RemoteDiskFiles(CommandInterpreter &interpreter,
+                                         CompletionRequest &request,
+                                         SearchFilter *searcher) {
+  lldb::PlatformSP platform_sp =
+      interpreter.GetDebugger().GetPlatformList().GetSelectedPlatform();
+  if (platform_sp)
+    platform_sp->AutoCompleteDiskFileOrDirectory(request, false);
+}
+
+void CommandCompletions::RemoteDiskDirectories(CommandInterpreter &interpreter,
+                                               CompletionRequest &request,
+                                               SearchFilter *searcher) {
+  lldb::PlatformSP platform_sp =
+      interpreter.GetDebugger().GetPlatformList().GetSelectedPlatform();
+  if (platform_sp)
+    platform_sp->AutoCompleteDiskFileOrDirectory(request, true);
+}
+
 void CommandCompletions::Modules(CommandInterpreter &interpreter,
                                  CompletionRequest &request,
                                  SearchFilter *searcher) {
   ModuleCompleter completer(interpreter, request);
 
   if (searcher == nullptr) {
     lldb::TargetSP target_sp = interpreter.GetDebugger().GetSelectedTarget();
     SearchFilterForUnconstrainedSearches null_searcher(target_sp);

 }
 
 void CommandCompletions::ProcessPluginNames(CommandInterpreter &interpreter,
                                             CompletionRequest &request,
                                             SearchFilter *searcher) {
   PluginManager::AutoCompleteProcessName(request.GetCursorArgumentPrefix(),
                                          request);
 }
 No newline at end of file

lldb/source/Commands/CommandObjectPlatform.cpp

 class CommandObjectPlatformSettings : public CommandObjectParsed {
 public:
   CommandObjectPlatformSettings(CommandInterpreter &interpreter)
       : CommandObjectParsed(interpreter, "platform settings",
                             "Set settings for the current target's platform, "
                             "or for a platform by name.",
                             "platform settings", 0),
         m_options(),
-        m_option_working_dir(LLDB_OPT_SET_1, false, "working-dir", 'w', 0,
+        m_option_working_dir(LLDB_OPT_SET_1, false, "working-dir", 'w',
+                             CommandCompletions::eRemoteDiskDirectoryCompletion,
                              eArgTypePath,
                              "The working directory for the platform.") {
     m_options.Append(&m_option_working_dir, LLDB_OPT_SET_ALL, LLDB_OPT_SET_1);
   }
 
   ~CommandObjectPlatformSettings() override = default;
 
 protected:

 public:
   CommandObjectPlatformFOpen(CommandInterpreter &interpreter)
       : CommandObjectParsed(interpreter, "platform file open",
                             "Open a file on the remote end.", nullptr, 0),
         m_options() {}
 
   ~CommandObjectPlatformFOpen() override = default;
 
+  void
+  HandleArgumentCompletion(CompletionRequest &request,
+                           OptionElementVector &opt_element_vector) override {
+    if (request.GetCursorIndex() == 0)
+      CommandCompletions::InvokeCommonCompletionCallbacks(
+          GetCommandInterpreter(),
+          CommandCompletions::eRemoteDiskFileCompletion, request, nullptr);
+  }
+
   bool DoExecute(Args &args, CommandReturnObject &result) override {
     PlatformSP platform_sp(
         GetDebugger().GetPlatformList().GetSelectedPlatform());
     if (platform_sp) {
       Status error;
       std::string cmd_line;
       args.GetCommandString(cmd_line);
       mode_t perms;
(lldb) platform get-file /the/remote/file/path /the/local/file/path
     // Push the data for the first and the second arguments into the
     // m_arguments vector.
     m_arguments.push_back(arg1);
     m_arguments.push_back(arg2);
   }
 
   ~CommandObjectPlatformGetFile() override = default;
 
+  void
+  HandleArgumentCompletion(CompletionRequest &request,
+                           OptionElementVector &opt_element_vector) override {
+    if (request.GetCursorIndex() == 0)
+      CommandCompletions::InvokeCommonCompletionCallbacks(
+          GetCommandInterpreter(),
+          CommandCompletions::eRemoteDiskFileCompletion, request, nullptr);
+    else if (request.GetCursorIndex() == 1)
+      CommandCompletions::InvokeCommonCompletionCallbacks(
+          GetCommandInterpreter(), CommandCompletions::eDiskFileCompletion,
+          request, nullptr);
+  }
+
   bool DoExecute(Args &args, CommandReturnObject &result) override {
     // If the number of arguments is incorrect, issue an error message.
     if (args.GetArgumentCount() != 2) {
       result.GetErrorStream().Printf("error: required arguments missing; "
                                      "specify both the source and destination "
                                      "file paths\n");
       result.SetStatus(eReturnStatusFailed);
       return false;
(lldb) platform get-size /the/remote/file/path
     arg1.push_back(file_arg_remote);
 
     // Push the data for the first argument into the m_arguments vector.
     m_arguments.push_back(arg1);
   }
 
   ~CommandObjectPlatformGetSize() override = default;
 
+  void
+  HandleArgumentCompletion(CompletionRequest &request,
+                           OptionElementVector &opt_element_vector) override {
+    if (request.GetCursorIndex() != 0)
+      return;
+
+    CommandCompletions::InvokeCommonCompletionCallbacks(
+        GetCommandInterpreter(), CommandCompletions::eRemoteDiskFileCompletion,
+        request, nullptr);
+  }
+
   bool DoExecute(Args &args, CommandReturnObject &result) override {
     // If the number of arguments is incorrect, issue an error message.
     if (args.GetArgumentCount() != 1) {
       result.GetErrorStream().Printf("error: required argument missing; "
                                      "specify the source file path as the only "
                                      "argument\n");
       result.SetStatus(eReturnStatusFailed);
       return false;
public:
   CommandObjectPlatformPutFile(CommandInterpreter &interpreter)
       : CommandObjectParsed(
             interpreter, "platform put-file",
             "Transfer a file from this system to the remote end.", nullptr, 0) {
   }
 
   ~CommandObjectPlatformPutFile() override = default;
 
+  void
+  HandleArgumentCompletion(CompletionRequest &request,
+                           OptionElementVector &opt_element_vector) override {
+    if (request.GetCursorIndex() == 0)
+      CommandCompletions::InvokeCommonCompletionCallbacks(
+          GetCommandInterpreter(), CommandCompletions::eDiskFileCompletion,
+          request, nullptr);
+    else if (request.GetCursorIndex() == 1)
+      CommandCompletions::InvokeCommonCompletionCallbacks(
+          GetCommandInterpreter(),
+          CommandCompletions::eRemoteDiskFileCompletion, request, nullptr);
+  }
+
   bool DoExecute(Args &args, CommandReturnObject &result) override {
     const char *src = args.GetArgumentAtIndex(0);
     const char *dst = args.GetArgumentAtIndex(1);
 
     FileSpec src_fs(src);
     FileSystem::Instance().Resolve(src_fs);
     FileSpec dst_fs(dst ? dst : src_fs.GetFilename().GetCString());
 

lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h

public:
   uint64_t ReadFile(lldb::user_id_t fd, uint64_t offset, void *data_ptr,
                     uint64_t len, Status &error) override;
 
   uint64_t WriteFile(lldb::user_id_t fd, uint64_t offset, const void *data,
                      uint64_t len, Status &error) override;
 
   lldb::user_id_t GetFileSize(const FileSpec &file_spec) override;
 
+  void AutoCompleteDiskFileOrDirectory(CompletionRequest &request,
+                                       bool only_dir) override;
+
   Status PutFile(const FileSpec &source, const FileSpec &destination,
                  uint32_t uid = UINT32_MAX, uint32_t gid = UINT32_MAX) override;
 
   Status CreateSymlink(const FileSpec &src, const FileSpec &dst) override;
 
   bool GetFileExists(const FileSpec &file_spec) override;
 
   Status Unlink(const FileSpec &path) override;

lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp

bool PlatformRemoteGDBServer::CloseFile(lldb::user_id_t fd, Status &error) {
   return m_gdb_client.CloseFile(fd, error);
 }
 
 lldb::user_id_t
 PlatformRemoteGDBServer::GetFileSize(const FileSpec &file_spec) {
   return m_gdb_client.GetFileSize(file_spec);
 }
 
+void PlatformRemoteGDBServer::AutoCompleteDiskFileOrDirectory(
+    CompletionRequest &request, bool only_dir) {
+  m_gdb_client.AutoCompleteDiskFileOrDirectory(request, only_dir);
+}
+
 uint64_t PlatformRemoteGDBServer::ReadFile(lldb::user_id_t fd, uint64_t offset,
                                            void *dst, uint64_t dst_len,
                                            Status &error) {
   return m_gdb_client.ReadFile(fd, offset, dst, dst_len, error);
 }
 
 uint64_t PlatformRemoteGDBServer::WriteFile(lldb::user_id_t fd, uint64_t offset,
                                             const void *src, uint64_t src_len,

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h

public:
 
   lldb::user_id_t OpenFile(const FileSpec &file_spec, File::OpenOptions flags,
                            mode_t mode, Status &error);
 
   bool CloseFile(lldb::user_id_t fd, Status &error);
 
   lldb::user_id_t GetFileSize(const FileSpec &file_spec);
 
+  void AutoCompleteDiskFileOrDirectory(CompletionRequest &request,
+                                       bool only_dir);
+
   Status GetFilePermissions(const FileSpec &file_spec,
                             uint32_t &file_permissions);
 
   Status SetFilePermissions(const FileSpec &file_spec,
                             uint32_t file_permissions);
 
   uint64_t ReadFile(lldb::user_id_t fd, uint64_t offset, void *dst,
                     uint64_t dst_len, Status &error);

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

if (SendPacketAndWaitForResponse(stream.GetString(), response, false) ==
     if (response.GetChar() != 'F')
       return UINT64_MAX;
     uint32_t retcode = response.GetHexMaxU64(false, UINT64_MAX);
     return retcode;
   }
   return UINT64_MAX;
 }
 
+void GDBRemoteCommunicationClient::AutoCompleteDiskFileOrDirectory(
+    CompletionRequest &request, bool only_dir) {
+  lldb_private::StreamString stream;
+  stream.PutCString("vFile:autocomplete:");
+  stream.PutHex32(only_dir ? 1 : 0);
+  stream.PutChar(',');
+  stream.PutStringAsRawHex8(request.GetCursorArgumentPrefix());
+  StringExtractorGDBRemote response;
+  if (SendPacketAndWaitForResponse(stream.GetString(), response, false) ==
+      PacketResult::Success) {
+    if (response.GetChar() != 'F')
+      return;
+
+    llvm::StringRef matches = response.GetStringRef().drop_front();
+    // Skip the first 'F' charactor.
+    while (matches.size()) {
+      std::pair<llvm::StringRef, llvm::StringRef> str_pair = matches.split(',');
+      request.AddCompletion(str_pair.first);
+      matches = str_pair.second;
+    }
+  }
+}
+
 Status
 GDBRemoteCommunicationClient::GetFilePermissions(const FileSpec &file_spec,
                                                  uint32_t &file_permissions) {
   std::string path{file_spec.GetPath(false)};
   Status error;
   lldb_private::StreamString stream;
   stream.PutCString("vFile:mode:");
   stream.PutStringAsRawHex8(path);

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.h

protected:
   PacketResult Handle_vFile_symlink(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_vFile_unlink(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_vFile_Stat(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_vFile_MD5(StringExtractorGDBRemote &packet);
 
+  PacketResult Handle_vFile_autocomplete(StringExtractorGDBRemote &packet);
+
   PacketResult Handle_qEcho(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_qModuleInfo(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_jModulesInfo(StringExtractorGDBRemote &packet);
 
   PacketResult Handle_qPlatform_shell(StringExtractorGDBRemote &packet);
 

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Host/Config.h"
 #include "lldb/Host/File.h"
 #include "lldb/Host/FileAction.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/SafeMachO.h"
+#include "lldb/Interpreter/CommandCompletions.h"
 #include "lldb/Interpreter/OptionArgParser.h"
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/Platform.h"
 #include "lldb/Utility/Endian.h"
 #include "lldb/Utility/GDBRemote.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/StreamString.h"
 #include "lldb/Utility/StructuredData.h"
+#include "lldb/Utility/TildeExpressionResolver.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Support/JSON.h"
 
 #include "ProcessGDBRemoteLog.h"
 #include "lldb/Utility/StringExtractorGDBRemote.h"
 
 #ifdef __ANDROID__
RegisterMemberFunctionHandler(
       &GDBRemoteCommunicationServerCommon::Handle_QLaunchArch);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_qLaunchSuccess,
       &GDBRemoteCommunicationServerCommon::Handle_qLaunchSuccess);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_QListThreadsInStopReply,
       &GDBRemoteCommunicationServerCommon::Handle_QListThreadsInStopReply);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_qEcho,
       &GDBRemoteCommunicationServerCommon::Handle_qEcho);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_qModuleInfo,
       &GDBRemoteCommunicationServerCommon::Handle_qModuleInfo);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_jModulesInfo,
       &GDBRemoteCommunicationServerCommon::Handle_jModulesInfo);
   RegisterMemberFunctionHandler(
RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_vFile_stat,
       &GDBRemoteCommunicationServerCommon::Handle_vFile_Stat);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_vFile_symlink,
       &GDBRemoteCommunicationServerCommon::Handle_vFile_symlink);
   RegisterMemberFunctionHandler(
       StringExtractorGDBRemote::eServerPacketType_vFile_unlink,
       &GDBRemoteCommunicationServerCommon::Handle_vFile_unlink);
+  RegisterMemberFunctionHandler(
+      StringExtractorGDBRemote::eServerPacketType_vFile_autocomplete,
+      &GDBRemoteCommunicationServerCommon::Handle_vFile_autocomplete);
 }
 
 // Destructor
 GDBRemoteCommunicationServerCommon::~GDBRemoteCommunicationServerCommon() {}
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerCommon::Handle_qHostInfo(
     StringExtractorGDBRemote &packet) {
GDBRemoteCommunicationServerCommon::Handle_vFile_unlink(
   packet.GetHexByteString(path);
   Status error(llvm::sys::fs::remove(path));
   StreamString response;
   response.Printf("F%u,%u", error.GetError(), error.GetError());
   return SendPacketNoLock(response.GetString());
 }
 
 GDBRemoteCommunication::PacketResult
+GDBRemoteCommunicationServerCommon::Handle_vFile_autocomplete(
+    StringExtractorGDBRemote &packet) {
+  packet.SetFilePos(::strlen("vFile:autocomplete:"));
+  const bool only_dir = (packet.GetHexMaxU32(false, 0) == 1);
+  if (packet.GetChar() != ',')
+    return SendErrorResponse(24); // FIXME: How to choose the error value?
+  std::string path;
+  packet.GetHexByteString(path);
+
+  StringList matches;
+  StandardTildeExpressionResolver resolver;
+  if (only_dir)
+    CommandCompletions::DiskDirectories(path, matches, resolver);
+  else
+    CommandCompletions::DiskFiles(path, matches, resolver);
+
+  StreamString response;
+  response.PutChar('F');
+  for (const auto &match : matches) {
+    if (response.GetSize() > 1)
+      response.PutChar(',');
+    response.PutCString(match.c_str());
+  }
+
+  return SendPacketNoLock(response.GetString());
+}
+
+GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerCommon::Handle_qPlatform_shell(
     StringExtractorGDBRemote &packet) {
   packet.SetFilePos(::strlen("qPlatform_shell:"));
   std::string path;
   std::string working_dir;
   packet.GetHexByteStringTerminatedBy(path, ',');
   if (!path.empty()) {
     if (packet.GetChar() == ',') {

lldb/source/Utility/StringExtractorGDBRemote.cpp

if (PACKET_STARTS_WITH("vFile:")) {
       else if (PACKET_STARTS_WITH("vFile:mode"))
         return eServerPacketType_vFile_mode;
       else if (PACKET_STARTS_WITH("vFile:MD5"))
         return eServerPacketType_vFile_md5;
       else if (PACKET_STARTS_WITH("vFile:symlink"))
         return eServerPacketType_vFile_symlink;
       else if (PACKET_STARTS_WITH("vFile:unlink"))
         return eServerPacketType_vFile_unlink;
-
+      else if (PACKET_STARTS_WITH("vFile:autocomplete"))
+        return eServerPacketType_vFile_autocomplete;
     } else {
       if (PACKET_STARTS_WITH("vAttach;"))
         return eServerPacketType_vAttach;
       if (PACKET_STARTS_WITH("vAttachWait;"))
         return eServerPacketType_vAttachWait;
       if (PACKET_STARTS_WITH("vAttachOrWait;"))
         return eServerPacketType_vAttachOrWait;
       if (PACKET_STARTS_WITH("vAttachName;"))

lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteDiskFileCompletion.py

+from gdbclientutils import GDBRemoteTestBase
+
+class TestGDBRemoteDiskFileCompletion(GDBRemoteTestBase):
+
+    def test_autocomplete_request(self):
+        """Test remote disk completion on remote-gdb-server plugin"""
+
+        try:
+            self.runCmd("platform select remote-gdb-server")
+            self.runCmd("platform connect connect://localhost:%d" %
+                        self.server.port)
+            self.assertTrue(self.dbg.GetSelectedPlatform().IsConnected())
+
+            self.complete_from_to('platform get-size t', 'platform get-size test')
+            self.complete_from_to('platform get-file t', 'platform get-file test')
+            self.complete_from_to('platform put-file foo t', 'platform put-file foo test')
+            self.complete_from_to('platform file open t', 'platform file open test')
+            self.complete_from_to('platform settings -w t', 'platform settings -w t')
+        finally:
+            self.dbg.GetSelectedPlatform().DisconnectRemote()

lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py

def respond(self, packet):
         if packet == "qGetWorkingDir":
             return self.qGetWorkingDir()
         if packet == "qOffsets":
             return self.qOffsets();
         if packet == "qsProcessInfo":
             return self.qsProcessInfo()
         if packet.startswith("qfProcessInfo"):
             return self.qfProcessInfo(packet)
+        if packet.startswith("vFile:autocomplete"):
+            return self.fAutocomplete()
 
         return self.other(packet)
 
     def qsProcessInfo(self):
         return "E04"
 
     def qfProcessInfo(self, packet):
         return "E04"
def QThreadSuffixSupported(self):
         return ""
 
     def QListThreadsInStopReply(self):
         return ""
 
     def qMemoryRegionInfo(self):
         return ""
 
+    def fAutocomplete(self):
+        return "Ftest"
+
     """
     Raised when we receive a packet for which there is no default action.
     Override the responder class to implement behavior suitable for the test at
     hand.
     """
     class UnexpectedPacketException(Exception):
         pass
 

lldb/test/API/tools/lldb-server/TestGdbRemoteCompletion.py

+import unittest2
+import gdbremote_testcase
+from lldbsuite.test.decorators import llgs_test
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbdwarf import DwarfOpcodeParser
+
+class GdbRemoteCompletionTestCase(gdbremote_testcase.GdbRemoteTestCaseBase, DwarfOpcodeParser):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    @llgs_test
+    def test_autocomplete_response(self):
+        self.init_llgs_test()
+        self.build()
+
+        server = self.connect_to_debug_monitor()
+        self.assertIsNotNone(server)
+
+        self.add_no_ack_remote_stream()
+
+        # complete disk files
+        self.test_sequence.add_log_lines(
+            ["read packet: $vFile:autocomplete:0,6d61696e#00", # 6d61696e is the byte array of string "main"
+             "send packet: $Fmain.cpp#00"],
+            True)
+        # complete disk directories
+        self.test_sequence.add_log_lines(
+            ["read packet: $vFile:autocomplete:1,746573#00", # 746573 is the byte array of string "tes"
+             "send packet: $Ftest/#00"],
+            True)
+
+        self.expect_gdbremote_sequence()