Re: [PATCH 6/6] gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

On 9/27/21 9:32 PM, Simon Marchi via Gdb-patches wrote:
> On 2021-09-10 23:16, Simon Marchi via Gdb-patches wrote:
>>>> Note that the problem described above happens today with "detach-on-fork
>>>> off" and "follow-fork-mode child", because we create new spaces for the
>>>> child.  This will have to be addressed later.
>>>>
>>>> Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
>>>> expected to have a location in each inferiors.  Without the fix, when
>>>> the two inferiors erroneously share a program space, GDB reports a
>>>> single location.
>>>
>>> So I wonder about the case where follow-fork-mode is parent and
>>> detach-on-fork is off?  In that case, should the existing aspace/pspace
>>> stay with the parent and the child get clones?  That is, using the
>>> follow-fork-mode setting to determine which inferior gets the existing
>>> aspace/pspace and assigning the cloned copies to the !follow-fork-mode
>>> inferior?
>>
>> I think that would work, to address the problem described above.
> 
> FYI, I tried doing the above (giving the original program space to the
> child with "follow-fork-mode child" and "detach-on-fork off") and I hit
> some problems.  Attached to the program space is the list of shared
> libraries.  So GDB would now think the parent has no shared library.  I
> added a solib_create_inferior_hook call to force re-discovering the
> shared libraries in the parent.  That seemed to work, but then in MI
> there were spurious =library-loaded events that made it look like
> inferior 1 re-loaded shared libraries.  I'm also worried about what
> other per-program space is kept, that could cause some kind of trouble
> for the parent.  So I will put this off for now, as it's not something
> that should be done in a rush, I think.
> 
> In the mean time, I'll re-test this series and push it if all seems
> good.

I'm seeing:
...
(gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=child:
detach-on-fork=on: cmd=next 2: test_follow_fork: break callee
info breakpoints 2^M
Num     Type           Disp Enb Address            What^M
2       breakpoint     keep y   <MULTIPLE>         ^M
2.1                         y   0x00000000004005ae in callee at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/foll-fork.c:9
inf 2^M
2.2                         y   0x00000000004005ae in callee at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/foll-fork.c:9
inf 1^M
(gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=child:
detach-on-fork=on: cmd=next 2: test_follow_fork: info breakpoints
...

Looks like the test-case expects first inf 1, then inf 2, and this is
the other way around.

Should the test-case regexp be updated?

Thanks,
- Tom