gdb: make post_startup_inferior a virtual method on inf_ptrace_target

While working on a later patch that required me to understand how GDB
starts up inferiors, I was confused by the
target_ops::post_startup_inferior method.

The post_startup_inferior target function is only called from
inf_ptrace_target::create_inferior.

Part of the target class hierarchy looks like this:

  inf_child_target
     |
     '-- inf_ptrace_target
            |
            |-- linux_nat_target
            |
            |-- fbsd_nat_target
            |
            |-- nbsd_nat_target
            |
            |-- obsd_nat_target
            |
            '-- rs6000_nat_target

Every sub-class of inf_ptrace_target, except rs6000_nat_target,
implements ::post_startup_inferior.  The rs6000_nat_target picks up
the implementation of ::post_startup_inferior not from
inf_ptrace_target, but from inf_child_target.

No descendent of inf_child_target, outside the inf_ptrace_target
sub-tree, implements ::post_startup_inferior, which isn't really
surprising, as they would never see the method called (remember, the
method is only called from inf_ptrace_target::create_inferior).

What I find confusing is the role inf_child_target plays in
implementing, what is really a helper function for just one of its
descendents.

In this commit I propose that we formally make ::post_startup_inferior
a helper function of inf_ptrace_target.  To do this I will remove the
::post_startup_inferior from the target_ops API, and instead make this
a protected, pure virtual function on inf_ptrace_target.

I'll remove the empty implementation of ::post_startup_inferior from
the inf_child_target class, and add a new empty implementation to the
rs6000_nat_target class.

All the other descendents of inf_ptrace_target already provide an
implementation of this method and so don't need to change beyond
making the method protected within their class declarations.

To me, this makes much more sense now.  The helper function, which is
only called from within the inf_ptrace_target class, is now a part of
the inf_ptrace_target class.

The only way in which this change is visible to a user is if the user
turns on 'set debug target 1'.  With this debug flag on, prior to this
patch the user would see something like:

  -> native->post_startup_inferior (...)
  <- native->post_startup_inferior (2588939)

After this patch these lines are no longer present, as the
post_startup_inferior is no longer a top level target method.  For me,
this is an acceptable change.

1 files changed, 0 insertions, 14 deletions

diff --git a/gdb/target.h b/gdb/target.h
index e709b7d..4736d32 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -626,8 +626,6 @@ struct target_ops
     virtual bool can_create_inferior ();
     virtual void create_inferior (const char *, const std::string &,
 				  char **, int);
-    virtual void post_startup_inferior (ptid_t)
-      TARGET_DEFAULT_IGNORE ();
     virtual int insert_fork_catchpoint (int)
       TARGET_DEFAULT_RETURN (1);
     virtual int remove_fork_catchpoint (int)
@@ -1688,18 +1686,6 @@ extern void target_kill (void);
 
 extern void target_load (const char *arg, int from_tty);
 
-/* Some targets (such as ttrace-based HPUX) don't allow us to request
-   notification of inferior events such as fork and vork immediately
-   after the inferior is created.  (This because of how gdb gets an
-   inferior created via invoking a shell to do it.  In such a scenario,
-   if the shell init file has commands in it, the shell will fork and
-   exec for each of those commands, and we will see each such fork
-   event.  Very bad.)
-
-   Such targets will supply an appropriate definition for this function.  */
-
-extern void target_post_startup_inferior (ptid_t ptid);
-
 /* On some targets, we can catch an inferior fork or vfork event when
    it occurs.  These functions insert/remove an already-created
    catchpoint for such events.  They return  0 for success, 1 if the