For what it's worth, we've been using lldb with ds2 to do remote debugging on Windows (x86) and Windows Phone (arm) and the lldb side of things works well with remote Windows targets. Besides porting lldb-server to Windows there shouldn't be any extra effort on the lldb side to do what Greg is talking about.
On Wed, Nov 30, 2016 at 9:35 AM, Greg Clayton via lldb-dev <lldb-dev@lists.llvm.org> wrote: > >> On Nov 29, 2016, at 10:16 PM, Zachary Turner <ztur...@google.com> wrote: >> >> What would it take to make it so that local and remote process plugins use >> the same exact interface? I mean in theory they're doing the same thing, >> just on a different machine. If they shared an identical interface then you >> could hook the lldb-server up to it and it would work either locally or >> remotely. >> >> What was the original motivation for having the api design of remote and >> local process plugins diverge? > > The plan was always do remote so we are always using one thing. We started > off thinking we wanted to have a native plug-in and a remote GDB server, but > when we found we didn't have serious performance issues we went the > lldb-server/debugserver route for everything on our end. lldb-server uses > NativeProcess and NativeThread as base classes that must be subclassed and we > would make a ProcessNative plug-in that used the native compiled version of > these (like lldb-server does), but then we have two code paths to test: > native and remote. So we either have to run twice the number of tests, one > local and one remote, so we can make sure native and remote work correctly, > or we just go one route. What would tend to happen is we would 99.9% of > people would do local debugging only and all bugs submitted would mostly be > bugs with the native implementation and remote would suffer and become > neglected. GDB had two different code paths for these so remote really did > suffer and we evolved to use remote only on all our systems. Another nice > reason for this is you can save the GDB remote packet log traffic when you do > encounter a bug and see exactly what happened when a bug happened. > > So due to history, we started thinking we would need both native and remote > plug-ins, but we migrated over time to just one solution for simpler testing, > ensuring remote debugging is rock solid since it is always used for local > debugging, and for the convenience of being able to completely lop all > traffic to/from the process with the GDB remote logs. > > Greg > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Stephane Sezer _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
