[PATCH] rs6000-nat.c: Call target_new_objfile_hook

[Kevin Buettner <kevinb@redhat.com>]

I've just committed the patch below.

While reviewing this patch, I was wondering why Nick needed to call
target_new_objfile_hook() directly.  The shared lib loading machinery
of other ports call symbol_file_add() instead.

It turns out that the ldinfo machinery in rs6000-tdep.c does much of
the work of symbol_file_add().  Apparently it can't call
symbol_file_add() directly since one of the pieces of information
obtained from the ldinfo is a file descriptor for the symbol file.  It
seems to me that if the name is always available, it might be better
to ignore the fd obtained from from the ldinfo and simply allow
symbol_file_add() to (re)open the file as is done on other ports.  I
haven't convinced myself that this will work yet though.  Also, there
may be other reasons why the rs6000 port does things the way they do.

So... since there are a number of things to sort out, I decided to
leave cleanup of the rs6000 shared lib machinery for another day
and commit Nick's patch instead.  (As noted in a comment below, this
patch is needed for AIX thread support.)

	From Nicholas Duffek:
	* rs6000-nat.c (vmap_ldinfo, xcoff_relocate_core): Call
	target_new_objfile_hook.

Index: rs6000-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-nat.c,v
retrieving revision 1.23
diff -u -p -r1.23 rs6000-nat.c
--- rs6000-nat.c	21 Mar 2002 13:52:57 -0000	1.23
+++ rs6000-nat.c	12 Jul 2002 18:39:05 -0000
@@ -832,6 +832,11 @@ vmap_ldinfo (LdInfo *ldi)
 	  /* relocate symbol table(s). */
 	  vmap_symtab (vp);
 
+	  /* Announce new object files.  Doing this after symbol relocation
+	     makes aix-thread.c's job easier. */
+	  if (target_new_objfile_hook && vp->objfile)
+	    target_new_objfile_hook (vp->objfile);
+
 	  /* There may be more, so we don't break out of the loop.  */
 	}
 
@@ -1109,6 +1114,9 @@ xcoff_relocate_core (struct target_ops *
 	}
 
       vmap_symtab (vp);
+
+      if (target_new_objfile_hook && vp != vmap && vp->objfile)
+	target_new_objfile_hook (vp->objfile);
     }
   while (LDI_NEXT (ldi, arch64) != 0);
   vmap_exec ();