From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26228 invoked by alias); 23 May 2006 22:59:32 -0000 Received: (qmail 26179 invoked by uid 22791); 23 May 2006 22:59:31 -0000 X-Spam-Check-By: sourceware.org Received: from e1.ny.us.ibm.com (HELO e1.ny.us.ibm.com) (32.97.182.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 May 2006 22:59:29 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4NMxRY6023245 for ; Tue, 23 May 2006 18:59:27 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4NMxRe9085426 for ; Tue, 23 May 2006 18:59:27 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4NMxQB0032076 for ; Tue, 23 May 2006 18:59:26 -0400 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4NMxQrh032025; Tue, 23 May 2006 18:59:26 -0400 Subject: Re: Chicken-or-egg problem with shared libraries From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Daniel Jacobowitz Cc: gdb@sources.redhat.com In-Reply-To: <20060523221114.GA8445@nevyn.them.org> References: <1148418266.315.45.camel@dufur.beaverton.ibm.com> <20060523221114.GA8445@nevyn.them.org> Content-Type: text/plain Date: Tue, 23 May 2006 23:27:00 -0000 Message-Id: <1148421377.315.65.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00340.txt.bz2 On Tue, 2006-05-23 at 18:11 -0400, Daniel Jacobowitz wrote: > I don't think you really understand the problem you're trying to fix - > what is it, by the way? Is it related to Alan's comment earlier > about the function descriptor lookup? > (sigh) You're right... I didn't look close enough. The problem I am trying to fix is that this gets executed: bkpt_at_symbol: warning (_("Unable to find dynamic linker breakpoint function.\n" "GDB will be unable to debug shared library initializers\n" "and track explicitly loaded dynamic code.")); I believe this is executed because although it finds "_dl_debug_state" (now that Alan made his change to BFD), on a ppc64 system, that symbol is not in the a code section and so it is rejected: > sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE); ^^^^^^^^^ The next symbol in the list being looked for is "._dl_debug_state", which is no longer to be found sense Alan removed the 'dot' symbols a while back. I guess I'll have to call "bfd_get_synthetic_symtab()" and look in the synthetic symtab it creates. Of course I'll have to first read in the dynamic symbol table which "bfd_get_synthetic_symtab()" needs. That should work. The only down side is that that work is then thrown away and then repeated when the symbols for the shared object that is the dynamic loader are read in later. But for 20 symbols or so, I guess that's not too bad. Thanks for setting me straight, -=# Paul #=-