From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16747 invoked by alias); 12 Mar 2007 05:16:45 -0000 Received: (qmail 16739 invoked by uid 22791); 12 Mar 2007 05:16:44 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Mar 2007 05:16:16 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id DC02A48CC4F for ; Mon, 12 Mar 2007 01:16:13 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17256-01-6 for ; Mon, 12 Mar 2007 00:16:13 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 4BD2C48CC41 for ; Mon, 12 Mar 2007 01:16:13 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 16CF0E7B38; Sun, 11 Mar 2007 22:16:46 -0700 (PDT) Date: Mon, 12 Mar 2007 05:16:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: [sparc-solaris] unexpected warning when starting program Message-ID: <20070312051646.GI14401@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00160.txt.bz2 I have noticed the following new warning in GDB 6.6 when running a program from GDB on sparc-solaris: (gdb) start Breakpoint 1 at 0x2d100: file a_test.adb, line 4. Starting program: /[...]/a_test warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1" [New LWP 1] [New LWP 2] [New LWP 3] a_test () at a_test.adb:4 4 procedure A_Test is The warning is harmless, but a bit of an eyesore, and it also throws off one of our testcases. I will see if I can enhance our testcase to ignore that warning, but I thought I'd share what I have found. Basically, the reason for the warning is that GDB thinks that the inferior unloaded ld.so.1. The reason for that is that, during startup, GDB does not immediately have access to base address of the dynamic linker structs. I suspect that this is because our real inferior hasn't been forked yet, or maybe is in the process of being forked. I haven't had time to look further into this. In this case, GDB falls back to a default method for computing the list of SOs: debug_base = locate_base (); /* If we can't find the dynamic linker's base structure, this must not be a dynamically linked executable. Hmm. */ if (! debug_base) return svr4_default_sos (); This method returns one object, the dynamic linker, with the following path: /usr/lib/ld.so.1. Slightly later, GDB tries to update its list of shared libraries again, and this time finds that base address. So it now scans a different memory region for that list of shared libraries. And in addition to that, there is the following code that was recently added: /* On Solaris, the dynamic linker is not in the normal list of shared objects, so make sure we pick it up too. Having symbol information for the dynamic linker is quite crucial for skipping dynamic linker resolver code. */ if (lm == 0 && ldsomap == 0) lm = ldsomap = solib_svr4_r_ldsomap (); The information extracted from this entry gives us the following path to the loader: /lib/ld.so.1. The paths are different!!! As a result, when GDB updates its table of shared libraries, it thinks these two entries are for different SOs, and thus unloads /usr/lib/ld.so. The problem is that we already have an internal breakpoint in ld.so, so GDB justifiably warns the user that one of the breakpoints inside the given SO will have to be temporarily disabled. I am a bit uncertain as to how to categorize this issue. Is this something that we can avoid? Or should it be considered an OS issue? I am not sure how to fix it either. On solaris 2.8 and 2.9, the two files are identical but distinct - one is not a link to the other. On solaris 2.10, however, one is a link of the other, so we could presumably check the fullpath instead of doing a direct name comparison. But that would be pretty expensive for just one type of host, no? Any other idea? -- Joel