[Lldb-commits] [PATCH] D99864: [lldb] Fork/vfork support via gdb-remote protocol [WIP]

[Michał Górny via Phabricator via lldb-commits]

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