From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27878 invoked by alias); 25 Apr 2012 04:06:06 -0000 Received: (qmail 27869 invoked by uid 22791); 25 Apr 2012 04:06:04 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pz0-f54.google.com (HELO mail-pz0-f54.google.com) (209.85.210.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 04:05:46 +0000 Received: by dady13 with SMTP id y13so1780933dad.13 for ; Tue, 24 Apr 2012 21:05:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.99 with SMTP id rb3mr3621747pbc.79.1335326746371; Tue, 24 Apr 2012 21:05:46 -0700 (PDT) Received: by 10.68.48.8 with HTTP; Tue, 24 Apr 2012 21:05:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 04:06:00 -0000 Message-ID: Subject: Re: hppa: glibc and gcc 4.6, "error: _rtld_global_ro causes a section type conflict" From: "Carlos O'Donell" To: John David Anglin Cc: linux-parisc , libc-ports@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00156.txt.bz2 On Tue, Apr 24, 2012 at 7:55 PM, John David Anglin w= rote: > 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, =A0it appears the bug is c= aused > by placing > function labels (plabels) in the constant pool. Interesting. > PA has done this for longer > than I can > remember, but it doesn't appear necessary. =A0As you know, only ia64 and = pa > use plabels. Yes, we both rely on the plabel code in glibc. > This causes the setting of default flags for .data.rel.ro which conflict > with those needed > for _rtld_global_ro in the dynamic linker. =A0The problem doesn't have > anything directly > to do with the handling of the variable _rtld_global_ro. =A0This was what= was > confusing > me as everything seemed generic. Me too. > I am testing a fix. =A0Your testcase compiles successfully with the fix. Excellent! > The issue is incredibly subtle. =A0I 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 kosh= er > from GCC POV. The dynamic linker isn't exactly kosher :-) Cheers, Carlos.