From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6207 invoked by alias); 29 Mar 2006 00:23:05 -0000 Received: (qmail 6191 invoked by uid 22791); 29 Mar 2006 00:23:05 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Mar 2006 00:23:04 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FOOT6-0007cx-6f for libc-hacker@sources.redhat.com; Tue, 28 Mar 2006 16:23:24 -0800 Date: Wed, 29 Mar 2006 00:23:00 -0000 Message-Id: <20060328.162324.107326686.davem@davemloft.net> To: libc-hacker@sources.redhat.com Subject: weird versioning crash... From: "David S. Miller" Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00044.txt.bz2 I've been working on a cryptic problem with MONO on sparc, and after finally getting a usable core dump I'm much closer to tracking things down. It crashes in do_lookup_x() while indexing into the map->l_versions[] array. This is /usr/bin/mono the dynamic linker is working on and the dynamic symbol table is very small, the entry of interest is "_etext": DYNAMIC SYMBOL TABLE: 00010830 g D *ABS* 00000000 () _etext 00010460 g DF .init 00000000 Base _init 00020a04 g D *ABS* 00000000 Base __bss_start 000209c8 DF *UND* 00000198 GLIBC_2.0 __libc_start_main 00010800 g DF .fini 00000000 Base _fini 00000000 w DF *UND* 0000010c GLIBC_2.1.3 __cxa_finalize 00020a04 g D *ABS* 00000000 Base _edata 00020a08 g D *ABS* 00000000 Base _end 00010830 g DO .rodata 00000004 Base _IO_stdin_used 000209ec DF *UND* 00001d68 VER_1 mono_main 00000000 w D *UND* 00000000 _Jv_RegisterClasses 00000000 w D *UND* 00000000 __gmon_start__ (Note the "()" version output.) do_lookup_x() is working on "_etext" right here: /* We can match the version information or use the default one if it is not hidden. */ ElfW(Half) ndx = verstab[symidx] & 0x7fff; if ((map->l_versions[ndx].hash != version->hash || strcmp (map->l_versions[ndx].name, version->name)) && (version->hidden || map->l_versions[ndx].hash || (verstab[symidx] & 0x8000))) /* It's not the version we want. */ continue; The "ndx" VERSYM entry for _etext is "0xa822", which is 0x2822 with the "hidden" 0x8000 bit masked out. That is way out of range. Sometimes things work because something happens to be mapped at that offset from the map->l_versions[] table. What I can't figure out is if that bogus hidden _etext entry is there due to a binutils bug, or perhaps bad arguments given to the link of the mono binary at build time. What could cause such a hidden version entry to _etext to end up in a binary like that? Thanks!