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: unassig...@gcc.gnu.org
ReportedBy: stephan.bergmann.second...@googlemail.com
The below error has first been discussed at
<http://gcc.gnu.org/ml/gcc/2011-08/msg00455.html>. It can at least be observed
when building recent versions of LibreOffice (e.g., revision
bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of
<git://anongit.freedesktop.org/libreoffice/core>) 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<cppu::WeakImplHelper1<ooo::vba::XCollection>
>::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<cppu::WeakImplHelper1<ooo::vba::XCollection>
>::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
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=148e0ccb50ce419e18e452eb7ccfe03cb4881634>,
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.
