Multiprocess on FreeBSD

[John Baldwin <jhb@FreeBSD.org>]

On 7/7/20 4:16 PM, John Baldwin wrote:
> FNAT: stop for LWP 101641 event 1 flags 0x18
> FLWP: fbsd_resume for ptid (70453, 101518, 0)
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> 
> Here you can see that the last call to fbsd_resume() used the ptid from
> inferior 1 instead of inferior 2, and inferior 1 didn't discard it's
> pending SIGTRAP but instead was killed by it.)

On this part, I turned on 'set debug infrun 1' and can see that
the core is trying to step over the breakpoint in the first
inferior.  However, it is not clearing the SIGTRAP signal to
GDB_SIGNAL_0 when resuming the first inferior but leaving it as
GDB_SIGNAL_TRAP.  This appears to be because start_step_over()
calls keep_going_pass_signal() instead of keep_going(), so
tp->control.stop_signal doesn't get reset.  I'm not sure if
stop_signal should have been cleared earlier somehow?

Hmm, if I add a hack to ignore SIGTRAP in fbsd_nat_target::resume(),
then what happens is that the first inferior runs to completion.
I can run the second inferior after switching to it, but I think the
behavior I probably want is for the core to not resume threads from
the non-current inferior instead?

One last test I tried is to do this sequence instead in the first
inferior:

(gdb) file /bin/ls
(gdb) start
(gdb) n

This gets the first inferior off of the breakpoint and the thread is
stopped for a hardware stepping trap instead.

I can then add an inferior do start and have it work fine, and I
can switch back and forth between the two inferiors stepping each
one.

So I think the issue here is that for some reason when the 'start'
command for inferior 2 tries to resume the inferior after getting
across the initial events for exec, it ends up resuming the wrong
inferior due to confusion about the thread stopped at a breakpoint.
However, it doesn't get confused if the thread is stopped for some
other reason.

-- 
John Baldwin