From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16249 invoked by alias); 12 Jul 2002 19:00:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16230 invoked from network); 12 Jul 2002 19:00:15 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 12 Jul 2002 19:00:15 -0000 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g6CJ10Q02226 for ; Fri, 12 Jul 2002 12:01:00 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g6CJ0CK07377 for gdb-patches@sources.redhat.com; Fri, 12 Jul 2002 12:00:12 -0700 Date: Fri, 12 Jul 2002 12:10:00 -0000 From: Kevin Buettner Message-Id: <1020712190012.ZM7376@localhost.localdomain> To: gdb-patches@sources.redhat.com Subject: [PATCH] rs6000-nat.c: Call target_new_objfile_hook MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00278.txt.bz2 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 ();