From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12159 invoked by alias); 15 Nov 2011 20:13:25 -0000 Received: (qmail 12142 invoked by uid 22791); 15 Nov 2011 20:13:22 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_OV X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 20:12:35 +0000 From: "nathan at acm dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure Date: Tue, 15 Nov 2011 20:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: gcov-profile X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nathan at acm dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg01564.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113 --- Comment #8 from Nathan Sidwell 2011-11-15 20:12:33 UTC --- On 11/15/11 10:03, markus at trippelsdorf dot de wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113 > > With your patch: > % c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe > -fprofile-generate -O0 test.ii > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: > error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against > '__gcov0__ZnwmPv' which may overflow at runtime; recompile with -fPIC Ok, I think I understand what's going on here. Here's a piece of code to explain: inline int *Foo () { static int x = 2; return &x; } int *(*Bar ()) () { return Foo; } although Foo::x is in the same comdat group as Foo, it is separately overridable at load time by another shared object. (of course such overriding completely breaks language semantics, but not ELF semantics). The linker's adhering to ELF semantics, and in this example the compiler emits: movq _ZZ3FoovE1x@GOTPCREL(%rip), %rax to get Foo::x's address. In the gcov case, it's emitting: movq __gcov0_js_malloc(%rip), %rax to access the first counter value. Although I think that's ok in a well-formed program, it's confusing the linker. that's unfortunate. (If you compile the above example with -fprofile-generate you'll see different access sequences for _ZZ3FoovE1x and __gcov0__Z3Foov.) I'm going to have to figure out why the right PIC sequence isn't being emitted.