gdb: call post_create_inferior at end of follow_fork_inferior

GDB doesn't handle well the case of an inferior using the JIT interface
to register JIT-ed objfiles and forking.  If an inferior registers a
code object using the JIT interface and then forks, the child process
conceptually has the same code object loaded, so GDB should look it up
and learn about it (it currently doesn't).

To achieve this, I think it would make sense to have the
inferior_created observable called when an inferior is created due to a
fork in follow_fork_inferior.  The inferior_created observable is
currently called both after starting a new inferior and after attaching
to an inferior, allowing various sub-components to learn about that new
executing inferior.  We can see handling a fork child just like
attaching to it, so any work done when attaching should also be done in
the case of a fork child.

Instead of just calling the inferior_created observable, this patch
makes follow_fork_inferior call the whole post_create_inferior function.
This way, the attach and follow-fork code code paths are more alike.

Given that post_create_inferior calls solib_create_inferior_hook,
follow_fork_inferior doesn't need to do it itself, so those calls to
solib_create_inferior_hook are removed.

One question you may have: why not just call post_create_inferior at the
places where solib_create_inferior_hook is currently called, instead of
after target_follow_fork?

 - there's something fishy for the second solib_create_inferior_hook
   call site: at this point we have switched the current program space
   to the child's, but not the current inferior nor the current thread.
   So solib_create_inferior_hook (and everything under, including
   check_for_thread_db, for example) is called with inferior 1 as the
   current inferior and inferior 2's program space as the current
   program space.  I think that's wrong, because at this point we are
   setting up inferior 2, and all that code relies on the current
   inferior.  We could just add a switch_to_thread call before it to
   make inferior 2 the current one, but there are other problems (see
   below).

 - solib_create_inferior_hook is currently not called on the
   `follow_child && detach_fork` path.  I think we need to call it,
   because we still get a new inferior in that case (even though we
   detach the parent).  If we only call post_create_inferior where
   solib_create_inferior_hook used to be called, then the JIT
   subcomponent doesn't get informed about the new inferior, and that
   introduces a failure in the new gdb.base/jit-elf-fork.exp test.

 - if we try to put the post_create_inferior just after the
   switch_to_thread that was originally at line 662, or just before the
   call to target_follow_fork, we introduce a subtle failure in
   gdb.threads/fork-thread-pending.exp.  What happens then is that
   libthread_db gets loaded (somewhere under post_create_inferior)
   before the linux-nat target learns about the LWPs (which happens in
   linux_nat_target::follow_fork).  As a result, the ALL_LWPS loop in
   try_thread_db_load_1 doesn't see the child LWP, and the thread-db
   target doesn't have the chance to fill in thread_info::priv.  A bit
   later, when the test does "info threads", and
   thread_db_target::pid_to_str is called, the thread-db target doesn't
   recognize the thread as one of its own, and delegates the request to
   the target below.  Because the pid_to_str output is not the expected
   one, the test fails.

   This tells me that we need to call the process target's follow_fork
   first, to make the process target create the necessary LWP and thread
   structures.  Then, we can call post_create_inferior to let the other
   components of GDB do their thing.

   But then you may ask: check_for_thread_db is already called today,
   somewhere under solib_create_inferior_hook, and that is before
   target_follow_fork, why don't we see this ordering problem!?  Well,
   because of the first bullet point: when check_for_thread_db /
   thread_db_load are called, the current inferior is (erroneously)
   inferior 1, the parent.  Because libthread_db is already loaded for
   the parent, thread_db_load early returns.  check_for_thread_db later
   gets called by linux_nat_target::follow_fork.  At this point, the
   current inferior is the correct one and the child's LWP exists, so
   all is well.

Since we now call post_create_inferior after target_follow_fork, which
calls the inferior_created observable, which calls check_for_thread_db,
I don't think linux_nat_target needs to explicitly call
check_for_thread_db itself, so that is removed.

In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp
test.  It makes an inferior register a JIT code object and then fork.
It then verifies that whatever the detach-on-fork and follow-fork-child
parameters are, GDB knows about the JIT code object in all the inferiors
that survive the fork.  It verifies that the inferiors can unload that
code object.

There isn't currently a way to get visibility into GDB's idea of the JIT
code objects for each inferior.  For the purpose of this test, add the
"maintenance info jit" command.  There isn't much we can print about the
JIT code objects except their load address.  So the output looks a bit
bare, but it's good enough for the test.

gdb/ChangeLog:

	* NEWS: Mention "maint info jit" command.
	* infrun.c (follow_fork_inferior): Don't call
	solib_create_inferior_hook, call post_create_inferior if a new
	inferior was created.
	* jit.c (maint_info_jit_cmd): New.
	(_initialize_jit): Register new command.
	* linux-nat.c (linux_nat_target::follow_fork): Don't call
	check_for_thread_db.
	* linux-nat.h (check_for_thread_db): Remove declaration.
	* linux-thread-db.c (check_thread_signals): Make static.

gdb/doc/ChangeLog:

	* gdb.texinfo (Maintenance Commands): Mention "maint info jit".

gdb/testsuite/ChangeLog:

	* gdb.base/jit-elf-fork-main.c: New test.
	* gdb.base/jit-elf-fork-solib.c: New test.
	* gdb.base/jit-elf-fork.exp: New test.

Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c

0 files changed, 0 insertions, 0 deletions