From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26492 invoked by alias); 28 Jul 2008 23:55:05 -0000 Received: (qmail 26476 invoked by uid 22791); 28 Jul 2008 23:55:04 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Jul 2008 23:54:37 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id 7BC1317F52A for ; Mon, 28 Jul 2008 20:41:06 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6SNsbIe2433264 for ; Mon, 28 Jul 2008 20:54:37 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6SNsU9W029383 for ; Mon, 28 Jul 2008 20:54:30 -0300 Received: from [9.8.11.76] ([9.8.11.76]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6SNsTPu029361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 20:54:30 -0300 Subject: [PATCH] Handle absence of DT_DEBUG while debugging ld.so From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb-patches@sourceware.org Content-Type: text/plain Date: Mon, 28 Jul 2008 23:55:00 -0000 Message-Id: <1217289278.16935.23.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00529.txt.bz2 Hi folks, When trying to debug ld.so, we may find that the DT_DEBUG entry in the .dynamic section is missing, thus GDB tries to look for the _r_debug minimal symbol, and eventually finds it. This works OK as long as the _r_debug minimal symbol is correct and initialized. In the case where GDB fetches an uninitialized _r_debug minimal symbol and tries to access its address, we have a memory access error, just like below: (gdb) r Starting program: /foo/lib/ld.so.1 Cannot access memory at address 0x2f648 Thus, we should guard this piece of code against uninitialized addresses so that GDB can skip this entry and look for another (hopefully) valid _r_debug symbol. Tested against HEAD for ppc32/ppc64 with no regressions. OK? Regards, Luis --- 2008-07-28 Luis Machado * solib-svr4.c (elf_locate_base): Check if msymbol's address is valid. Index: gdb/solib-svr4.c =================================================================== --- gdb.orig/solib-svr4.c 2008-07-28 14:35:20.000000000 -0700 +++ gdb/solib-svr4.c 2008-07-28 16:11:42.000000000 -0700 @@ -508,9 +508,14 @@ return dyn_ptr; /* This may be a static executable. Look for the symbol - conventionally named _r_debug, as a last resort. */ + conventionally named _r_debug, as a last resort and check if + the address contained in the minimal symbol is valid before + proceeding. */ msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile); - if (msymbol != NULL) + if (msymbol != NULL + && !target_read_memory (SYMBOL_VALUE_ADDRESS (msymbol), + (gdb_byte *)&dyn_ptr, + TYPE_LENGTH (builtin_type_void_data_ptr))) return SYMBOL_VALUE_ADDRESS (msymbol); /* DT_DEBUG entry not found. */