labath added a comment. In https://reviews.llvm.org/D35311#814941, @jingham wrote:
> This isn't about this patch, but replying to: > > > debugserver replies to the k packet instead of just dropping the connection > > - stopping code adjusted, although we should probably consider aligning the > > behavior of the two stubs in this case > > Especially when dealing with flakey connections, knowing that you are done > with a target was really handy. People what to hit "rerun" in some UI and > have the rerun happen instantly, but if you have no way of knowing when the > former process actually died, you have to introduce delays, which slows this > down. This is particularly true when talking to an OS that really wants only > one copy of an "app" running at a time (e.g. iOS) but is more generally > useful for responsiveness. And if something goes wrong with killing the > target, we could even use the new error reply strings to give more info about > this. Yes, I can totally believe that the response to that packet can be useful. I'm not actually sure that changing the debugserver behavior is the best solution here, I just think that we should pick one behavior and have both of the stubs act the same way. It's a bit unfortunate that this is in violation of the gdb-remote protocol, but I guess if a client is expecting the connection to be dropped, it is unlikely it will get confused by an OK response (OTOH, maybe we could use the fact that the connection was dropped as a signal that the kill has completed). https://reviews.llvm.org/D35311 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
