From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 377 invoked by alias); 31 Aug 2006 15:38:15 -0000 Received: (qmail 360 invoked by uid 22791); 31 Aug 2006 15:38:15 -0000 X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Aug 2006 15:38:11 +0000 Received: from sunsite.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k7VFc16W026198; Thu, 31 Aug 2006 17:38:01 +0200 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.13.1/8.13.1/Submit) id k7VFc184026197; Thu, 31 Aug 2006 17:38:01 +0200 Date: Thu, 31 Aug 2006 15:38:00 -0000 From: Jakub Jelinek To: Ulrich Drepper Cc: Glibc hackers Subject: [PATCH] Fix tst-addr1 on ppc64 and ia64 Message-ID: <20060831153800.GQ4556@sunsite.mff.cuni.cz> Reply-To: Jakub Jelinek Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i 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-08/txt/msg00037.txt.bz2 Hi! On ppc64 and ia64 &printf is put into GOT, so the SHN_UNDEF printf symbol has zero st_value and thus dladdr (&printf, ...) returns a symbol in libc.so. But, unfortunately, in libc.so _IO_printf is an alias to printf, both are global symbols and have the same address and size. Which one comes first in the hash table depends on the linker. 2006-08-31 Jakub Jelinek * elf/tst-addr1.c (do_test): Allow i.dli_sname "_IO_printf". --- libc/elf/tst-addr1.c.jj 2006-08-24 22:18:59.000000000 +0200 +++ libc/elf/tst-addr1.c 2006-08-31 17:27:20.000000000 +0200 @@ -12,7 +12,14 @@ do_test (void) return 1; } printf ("found symbol %s in %s\n", i.dli_sname, i.dli_fname); - return i.dli_sname == NULL || strcmp (i.dli_sname, "printf") != 0; + return i.dli_sname == NULL + || (strcmp (i.dli_sname, "printf") != 0 + /* On architectures which create PIC code by default + &printf may resolve to an address in libc.so + rather than in the binary. printf and _IO_printf + are aliased and which one comes first in the + hash table is up to the linker. */ + && strcmp (i.dli_sname, "_IO_printf") != 0); } #define TEST_FUNCTION do_test () Jakub