Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(and implicitly resumes the parent).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Merged D100541 and client fork/vfork stop infos from D100208 into this one. Included fork-events+ and vfork-events+ in client qSupported.
In other words, this is a complete commit that moves fork/vfork handling from server to client. qSupported enables Process plugins to start emitting fork/vfork stop reasons. The stop handler triggers DidFork() and DidVFork() handlers in gdb-remote process plugin, that send detach packet with the specific PID.
The functionality is covered by existing tests in test/Shell/Subprocess.
@labath, now's a curious problem I've seen very rarely (I mean, 1 out of 150 attempts or so):
1: (lldb) command source -s 0 '/home/mgorny/git/llvm-project/build.gentoo/tools/lldb/test/Shell/lit-lldb-init' 2: Executing commands in '/home/mgorny/git/llvm-project/build.gentoo/tools/lldb/test/Shell/lit-lldb-init'. 3: (lldb) # LLDB init file for the LIT tests. 4: (lldb) settings set symbols.enable-external-lookup false 5: (lldb) settings set plugin.process.gdb-remote.packet-timeout 60 6: (lldb) settings set interpreter.echo-comment-commands false 7: (lldb) settings set symbols.clang-modules-cache-path "/home/mgorny/git/llvm-project/build.gentoo/lldb-test-build.noindex/module-cache-lldb" 8: (lldb) settings set target.auto-apply-fixits false 9: (lldb) settings set target.inherit-tcc true 10: (lldb) settings set target.detach-on-error false 11: (lldb) target create "/home/mgorny/git/llvm-project/build.gentoo/tools/lldb/test/Shell/Subprocess/Output/vfork-follow-parent-wp.test.tmp" 12: Current executable set to '/home/mgorny/git/llvm-project/build.gentoo/tools/lldb/test/Shell/Subprocess/Output/vfork-follow-parent-wp.test.tmp' (x86_64). 13: (lldb) command source -s 0 '/home/mgorny/git/llvm-project/lldb/test/Shell/Subprocess/vfork-follow-parent-wp.test' 14: Executing commands in '/home/mgorny/git/llvm-project/lldb/test/Shell/Subprocess/vfork-follow-parent-wp.test'. 15: (lldb) process launch -s 16: Process 240829 launched: '/home/mgorny/git/llvm-project/build.gentoo/tools/lldb/test/Shell/Subprocess/Output/vfork-follow-parent-wp.test.tmp' (x86_64) 17: (lldb) watchpoint set variable -w write g_val 18: Watchpoint created: Watchpoint 1: addr = 0x00404054 size = 4 state = enabled type = w 19: watchpoint spec = 'g_val' 20: new value: 0 21: (lldb) continue 22: Process 240829 resuming 23: Process 240829 stopped 24: * thread #1, name = 'vfork-follow-pa', stop reason = signal SIGSTKFLT 25: frame #0: 0x00007ffff7b3b708 libc.so.6`__vfork + 8 26: libc.so.6`__vfork: 27: -> 0x7ffff7b3b708 <+8>: pushq %rdi 28: 0x7ffff7b3b709 <+9>: cmpl $0xfffff001, %eax ; imm = 0xFFFFF001 29: 0x7ffff7b3b70e <+14>: jae 0x7ffff7b3b711 ; <+17> 30: 0x7ffff7b3b710 <+16>: retq
i.e. vfork() emits SIGSTKFLT for some reason and this confuses the test. I have no clue why this happens — signal(7) says that this signal is unused. It might be a bug in glibc, or in glibc-2.33 more specifically.