[Lldb-commits] [PATCH] D98822: [lldb] follow-fork/vfork support [WIP]

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Mar 22 10:38:51 PDT 2021


jingham added a comment.

In D98822#2640881 <https://reviews.llvm.org/D98822#2640881>, @labath wrote:

> In D98822#2637871 <https://reviews.llvm.org/D98822#2637871>, @jingham wrote:
>
>> The gdb model - since gdb only supports one debugee per gdb - is to either follow the fork or follow the parent.  It would be more in keeping with lldb's model to make a new target for the child side of the fork, and use that to follow the child.  That way you can continue to debug both the parent and the child processes.  It doesn't look like you've gotten that far yet, but IMO that's the direction we should be going for lldb.
>
> This is no longer true -- gdb supports multiple inferiors these days (I'm not sure when exactly did it grow that support). The automatic detaching of the fork child can be disabled by the "detach-on-fork" setting, at which point you get two inferiors for each fork.
>
> Michal doesn't appear to be interested in this feature right now, just the ability to follow the child process. I think that's fair, as the two inferior setup would be more complicated. However, I am keeping this scenario in mind and making sure that it's possible to support it in the future. The idea is that at the gdb protocol level we will have the notion of two inferiors (using the same syntax that gdb does), but the only thing that the client (and server, mostly) support is to immediately detach from one of the processes after a fork. Later this could be changed to do something more interesting.

Oh, I'm glad to hear that, both about gdb and what sounds like a good plan for lldb going forward..  We just need to make sure supporting both sides of the fork stays the natural direction, even if we don't support it right off.

Using background apps to create sandbox barriers for lower-permissions tasks is becoming a more and more common architecture.  Having a framework for doing "task level" debugging that can cross these process barriers as the tasks move back and forth would be a great addition to lldb, but for that we need to be able to keep both sides of the fork under lldb's control.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98822/new/

https://reviews.llvm.org/D98822



More information about the lldb-commits mailing list