slydiman wrote: > One way I can imagine this happening is if the FileSystem instance was local > to a GDBRemoteCommunicationServerPlatform instance -- rather than the thread > it happens to be (mostly) running on. This will require more changes to, > basically, plumb the filesystem instance to every place that needs to be used > from the platform object, but I think that's actually a good thing. It will > give us a record of which code is prepared to deal with virtualized > filesystems and which one isn't. I just don't think we can assume that all > our code (present and future) will handle the per-thread filesystem situation > correctly.
GDBRemoteCommunicationServerPlatform extends GDBRemoteCommunicationServerCommon, GDBRemoteCommunication, etc. The working directory may be used for own tasks (for example load/save settings) and to handle request with a relative path. Most such requests are handled in GDBRemoteCommunicationServerCommon. It seems everything works correctly since all tests passed. > (That said, it still may be better to just spawn a new process instead. I > don't think this is a particularly hot code path (I think the test suite is > basically the only user of multithreaded platforms), and it will make sure we > don't hit the ETXTBSY issue). How will the spawned process help? I think the only way to fix ETXTBSY issue is to copy the executable to the target and launch it from the same process. It seems MacOS uses system's gdbserver instead of `lldb-server gdbserver`. Please correct me if I'm wrong. So ETXTBSY issue is the design issue. Probably it is necessary to move vFile:open, vFile:pwrite, vFile:close to gdbserver somehow to fix ETXTBSY issue. https://github.com/llvm/llvm-project/pull/100670 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
