From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10485 invoked by alias); 24 Apr 2012 23:55:42 -0000 Received: (qmail 10475 invoked by uid 22791); 24 Apr 2012 23:55:42 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from blu0-omc4-s2.blu0.hotmail.com (HELO blu0-omc4-s2.blu0.hotmail.com) (65.55.111.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Apr 2012 23:55:29 +0000 Received: from BLU0-SMTP9 ([65.55.111.135]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 16:55:28 -0700 Message-ID: Received: from [192.168.2.10] ([69.158.168.8]) by BLU0-SMTP9.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 16:55:27 -0700 From: John David Anglin To: Carlos O'Donell In-Reply-To: Subject: Re: hppa: glibc and gcc 4.6, "error: _rtld_global_ro causes a section type conflict" References: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Apr 2012 23:55:00 -0000 CC: linux-parisc , libc-ports@sourceware.org Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00155.txt.bz2 On 15-Apr-12, at 11:00 AM, Carlos O'Donell wrote: > When compiling glibc on magnum with gcc-4.6 I get an odd failure about > section type conflicts. After discussing the issue with Jakub Jelinek, it appears the bug is caused by placing function labels (plabels) in the constant pool. PA has done this for longer than I can remember, but it doesn't appear necessary. As you know, only ia64 and pa use plabels. This causes the setting of default flags for .data.rel.ro which conflict with those needed for _rtld_global_ro in the dynamic linker. The problem doesn't have anything directly to do with the handling of the variable _rtld_global_ro. This was what was confusing me as everything seemed generic. I am testing a fix. Your testcase compiles successfully with the fix. The issue is incredibly subtle. I would guess it was just a matter of luck that other targets aren't affected given that the code in rtld.c is not exactly exactly kosher from GCC POV. Regards, Dave -- John David Anglin dave.anglin@bell.net