mgorny added a comment. In D99864#2676389 <https://reviews.llvm.org/D99864#2676389>, @labath wrote:
> I'm going to have more questions, but let me start with this: What should the > (v)fork-events extension actually mean? In the client, I guess it > demonstrates its willingness to receive the appropriate type of event. But > what should it mean on the server? Is it like "I promise to stop on every > (v)fork", or just something like "hey, I know this word"? The second meaning > only makes sense if these (v)fork-events come with some new protocol > extensions/packets that the client can use when communicating with the > server. Such is the case with the multiprocess extension (new thread id > syntax), but I am not aware of anything similar in for these features. Are > there any? The gdb documentation (//This feature indicates whether GDB > supports fork event extensions to the remote protocol. GDB does not use such > extensions unless the stub also reports that it supports them by including > ‘fork-events+’ in its ‘qSupported’ reply. //) seems to indicate they might > exist, but I am not sure what would they be... > > If there aren't any, then it would probably be better to use the first > "definition" of the feature (or something similar), as the client can > legitimately be interested in whether it will be able to intercept forks or > not. And if that's the case, then we should first consult the relevant > NativeProcess class before we reply (v)fork-events+. Reading GDB code, the server indicates `fork-events+` only if the target explicitly supports it. In case of Linux, it even goes as far as to perform a runtime test for fork reporting but I don't think we want to go that far. The support for particular kind of events is reported independently of whether client indicated support. On client end, the server indication seems to be used to determine whether 'inserting' fork catchpoint succeeds or fails (it does not perform any comm itself since catchpoints just react to fork events from server). If I'm reading the code correctly, it also ignores fork/vfork events if `qSupported` did not indicate support earlier, though tbh I don't think that makes much sense — I suppose it just leads to UB since server sent a stop and we do nothing about it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99864/new/ https://reviews.llvm.org/D99864 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
