Hi Alexandros,
Could you use the linaro-toolchain list for stuff like this please?
You're more likely to find somebody who knows the answer that way.
I'm pretty sure the problem is not the compiler because, as far as I can
see, both architectures' compilers emit ".weak" directives. If there is
a problem, I'd say it's in the linker.
Your test case gives two different addresses on Lucid x86, and on ARM
(so you say, I've not tested it), but the same address twice on Precise.
This is a surprising result. *I* would have expected that static values
in different dlopen'd libraries would not be unified, but apparently
they are ... somtimes.
I'm afraid I don't really have any insight here. :(
Anyway, regardless of whether one is correct, or not, I'd suggest *not*
relying on this behaviour - it's clearly not portable. I say leave it at
arm's length in production software for a few years.
Andrew
On 06/03/12 14:27, Alexandros Frantzis wrote:
On Tue, Mar 06, 2012 at 09:51:01AM +0800, Sam Spilsbury wrote:
On Mon, Mar 5, 2012 at 11:50 PM, Alexandros Frantzis
<alexandros.frant...@linaro.org> wrote:
Hi all,
this is an update on my progress with the updated compiz branches.
I have been trying to run our update compiz branches
(compiz-*/linaro-gles2-update) on ARM (precise armhf), but I have stumbled onto
the same issue Marc reported some days ago. In particular, I get:
/usr/bin/compiz (core) - Fatal: Private index value "15CompositeWindow_index_4"
already stored in screen.
/usr/bin/compiz (core) - Fatal: Private index value "15CompositeScreen_index_4"
already stored in screen.
and then a segfault when I try to run compiz.
Note that I *don't* have this problem when running on x86_64 precise.
The issue can be recreated with:
$ compiz composite opengl
I added some debugging messages to pluginclasshandler.h to get a better
feeling of what is going on, and ran on both my desktop and on ARM.
This is the output near the point when GLScreen get initialized:
...
compiz (core) - Info: get(): mIndex.initiated for "8GLScreen_index_4" : 0
compiz (core) - Info: initializeIndex(): Initializining index value
"8GLScreen_index_4"
compiz (core) - Info: initializeIndex(): Private index value added for
"8GLScreen_index_4"
compiz (core) - Info: getInstance(): Get instance for "8GLScreen_index_4"
compiz (core) - Info: getInstance(): Spawning new class for "8GLScreen_index_4"
compiz (core) - Info: ctor(): mIndex.initiated for "8GLScreen_index_4" : 1
compiz (core) - Info: ctor(): Increasing reference count for
"8GLScreen_index_4": 1
--- x86_64 ---
compiz (core) - Info: get(): mIndex.initiated for "15CompositeScreen_index_4" :
1
--- armhf ---
compiz (core) - Info: get(): mIndex.initiated for "15CompositeScreen_index_4" : 0
compiz (core) - Info: initializeIndex(): Initializining index value
"15CompositeScreen_index_4"
compiz (core) - Fatal: initializeIndex(): Private index value
"15CompositeScreen_index_4" already stored in screen.
After the composite plugin loads and mIndex.initiated is set to 1,
place a watchpoint on mIndex.initiated (it should be a separate
template instantiation for each different class) and check if it
changes, or check if we are reading mIndex.initiated from a different
address, and if so, check the addresses of this for each constructor
and destructor being called. (could be a compiler bug, I've hit these
on this part of the code before).
-------------
In the armhf case, CompositeScreen is erroneously considered not
initialized, and is initialiazed again, therefore messing up the plugin system.
I am trying to figure out if this is a manifestation of some kind of memory
corruption that doesn't affect us on x86_64 for whatever reason (alignment,
integer size etc), or something completely different.
Thoughts?
Thanks,
Alexandros
--
Sam Spilsbury
Hi all,
(I have also added Michael, Andrew and Ulrich from the Linaro toolchain group
to the recipients. Hi!)
Checking the addresses, as Sam suggested, I found that there are two different
PluginClassHandler<CompositeScreen, CompScreen, 4>::mIndex and
PluginClassHandler<CompositeWindow, CompWindow, 4>::mIndex objects.
After a bit of investigation, objdump gave an explanation:
objdump -t /usr/lib/compiz/libcomposite.so | c++filt | grep mIndex
-- x86_64 --
0000000000277a80 u O .bss 0000000000000010
PluginClassHandler<CompositeWindow, CompWindow, 4>::mIndex
0000000000277a70 u O .bss 0000000000000010
PluginClassHandler<CompositeScreen, CompScreen, 4>::mIndex
-- armhf --
00065648 w O .bss 00000010 PluginClassHandler<CompositeWindow, CompWindow,
4>::mIndex
00065658 w O .bss 00000010 PluginClassHandler<CompositeScreen, CompScreen,
4>::mIndex
------------
And the same kind of output for libopengl.so
On x86_64 the symbols are marked 'u': 'unique global', whereas on armhf
they are marked 'w': 'weak'. This seems to be causing our troubles.
I have produced a small test case for this:
http://people.linaro.org/~afrantzis/cpp_unique_global.tar.gz
Building and running 'LD_LIBRARY_PATH=. ./main' on x86_64 prints out f1 and f2
with the same address, whereas on armhf the addresses are different (i.e. two
different objects). On x86_64 the symbol A<int>::a is 'u', on armhf it is 'w'.
For completeness, when running without templates (edit a.h to change) the two
printed addresses are different on both x86_64 and armhf. Also A::a is 'g':
'normal global' for both.
Michael, Andrew, Ulrich can you please give us some insight into the situation?
Does this seem like a compiler or linker bug on ARM, or is the code depending
on undefined behavior, or something different? I have pasted the used g++
versions at the end of the email.
Thanks,
Alexandros
--- g++ x86_64 --
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu2)
--- g++ armhf --
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu2)
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
