From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4204 invoked by alias); 23 May 2006 23:27:08 -0000 Received: (qmail 4155 invoked by uid 22791); 23 May 2006 23:27:08 -0000 X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 May 2006 23:27:05 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4NNR4SK031919 for ; Tue, 23 May 2006 19:27:04 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4NNR3ph257796 for ; Tue, 23 May 2006 17:27:03 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4NNR3eU019224 for ; Tue, 23 May 2006 17:27:03 -0600 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4NNR2qn019192; Tue, 23 May 2006 17:27:03 -0600 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: <20060523230237.GA9621@nevyn.them.org> References: <1148418266.315.45.camel@dufur.beaverton.ibm.com> <20060523221114.GA8445@nevyn.them.org> <1148421377.315.65.camel@dufur.beaverton.ibm.com> <20060523230237.GA9621@nevyn.them.org> Content-Type: text/plain Date: Wed, 24 May 2006 01:12:00 -0000 Message-Id: <1148423034.315.79.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/msg00342.txt.bz2 On Tue, 2006-05-23 at 19:02 -0400, Daniel Jacobowitz wrote: > On Tue, May 23, 2006 at 02:56:17PM -0700, PAUL GILLIAM wrote: > > 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); > > ^^^^^^^^^ > > I understood from Alan that GDB ought to actually deal with the > function descriptor here and go from that to the code address; or is > that wrong? What Alan thinks is that GDB should do so *everywhere*, not just here. What we do instead is to synthesize the 'dot' symbols, essentially dealing with this problem once, when the symbols are loaded, rather than each time a function's entry point address is needed. Here is a recent statement of Alan's: > Really, gdb should be taught how to do without the synthetic sym crutch. The fancy way would be to do the translation as needed, but cache the results. I don't want to solve this today, just so that this breakpoint can be set: I am content to continue using the synthetic sym crutch for a while longer. This particular need for the crutch was just overlooked when the use of 'dot' symbols was originally abandoned. -=# Paul #=-