From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8286 invoked by alias); 31 Aug 2011 20:28:12 -0000 Received: (qmail 8268 invoked by uid 22791); 31 Aug 2011 20:28:10 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Wed, 31 Aug 2011 20:27:40 +0000 From: "stephan.bergmann.secondary at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/50255] New: Linker stumbles over non-grouped text/rodata for a non-virtual thunk Date: Wed, 31 Aug 2011 21:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: stephan.bergmann.secondary at googlemail dot com 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: 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-08/txt/msg02582.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 Bug #: 50255 Summary: Linker stumbles over non-grouped text/rodata for a non-virtual thunk Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: stephan.bergmann.secondary@googlemail.com The below error has first been discussed at . It can at least be observed when building recent versions of LibreOffice (e.g., revision bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of ) on Fedora 15 i386 (i.e., with GCC 4.6.0 20110603 (Red Hat 4.6.0-10)). The problem is that linking together objects via g++ -shared vbarange.o vbasheetobjects.o fails with errors like `.L109' referenced in section `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBase >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' of vbasheetobjects.o: defined in discarded section `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual thunk to ScVbaCollectionBase >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' of vbasheetobjects.o The two C++ files vbarange.cxx and vbasheetobjects.cxx are compiled with identical g++ command lines, including switches -fPIC -fno-common -pipe -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fexceptions -fno-enforce-eh-specs -Os besides more mundane -D, -I, -M, and -W switches. Both objects include code for the _ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_ function, but there are two things that are odd: First, the code emitted for the two functions is rather different in the two object files, even though both are compiled with identical command line switches. One difference is that In vbasheetobjects.o, the code contains a rodata section (see below) with a number of labels into code that follows, whereas the code in vbarange.o does not contain such a rodata section. Could it be that -Os can cause these differences? (If necessary, I can easily make available the -S output for the relevant code from the two different files.) Second, the directive for the rodata section mentioned above is .section .rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,"aG",@progbits,_ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,comdat while the directive for the corresponding text section (split in multiple parts) is .section .text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,"axG",@progbits,_ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollectionEEEE4ItemERKN3com3sun4star3uno3AnyESD_,comdat Note the difference in the GroupName part of the .section directives, the rodata section using the symbol denoting the plain function instead of the non-virtual thunk. The theory is that the rodata and text sections should belong to a single group, so that the linker would either keep or remove them together. What apparently happens instead is that the linker uses the text section from vbarange.o, drops the corresponding text section from vbasheetobjects.o, and then stumbles over the left-over rodata section. (Manually adapting the GroupName of the rodata section directive to match the text section makes the link succeed.) The problem has been worked around for now in LibreOffice by compiling vbasheetobjects.o without -Os (see , i.e., that change must be reverted before the problem can be observed in the code revision mentioned at the beginning), which makes the problem go aways rather by chance.