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

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

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.

Simon