Re: Multiprocess on FreeBSD

[John Baldwin <jhb@FreeBSD.org>]

On 7/7/20 5:10 PM, John Baldwin wrote:
> 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.

I had to add a 'fbsd_nat_target::supports_multi_process' method and
now it seems to work fine.

It does depend on the fix to use find_inferior_pid() to work.

-- 
John Baldwin