Problem running updated compiz branches on ARM
alexandros.frantzis at linaro.org
Thu Mar 8 09:54:57 UTC 2012
On Wed, Mar 07, 2012 at 12:57:55AM +0000, Ramana Radhakrishnan wrote:
> (Hit send too soon on my last mail and appear to have removed linaro-toolchain
> Apologies to those who get duplicates)
> On Tue, Mar 06, 2012 at 04:00:36PM +0000, Andrew Stubbs wrote:
> > 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 suspect this is a compiler bug around the handling
> of STB_GNU_UNIQUE_OBJECT- something I suspect was invented to solve the problem
> in this space - it should all just work in the GNU/Linux world.
> The assembler files on x86_64 from the small testcase have
> .type _ZN1AIiE1aE, @gnu_unique_object
> while the one in case of ARM doesn't have this.
> However my suspicion about the problem is around the fact that GCC
> in it's build process
> emits .type x, @gnu_unique_object to check whether this feature
> is supported by the GNU assembler. Historically `@' has been a comment
> character on ARM . So, the compiler doesn't
> know that GNU_UNIQUE_OBJECT is supported in the assembler and it all
> falls apart very quickly after that and therefore doesn't
> generate such code. ...
> The quickest workaround IMHO is for a new compiler build that is
> rebuilt with --enable-gnu-unique-object. Given this feature went into
> a not very recent version of binutils, I would expect
> most recent assemblers to support this feature and for this to
> just work (TM). I would expect this configure option to be turned
> on for cross-compilers as well. It might also be the fastest
> way of testing this feature.
> Thoughts ? I would like another set of eyes on this.
> I verified this works on an armel box by :
> (natty)lp-ramana at jenipapo:~/cpp_unique_global$ diff -au f12.s f1.s | less
> --- f12.s 2012-03-07 00:47:32.000000000 +0000
> +++ f1.s 2012-03-06 23:25:54.000000000 +0000
> @@ -130,7 +130,7 @@
> .weak _ZN1AIiE1aE
> .section .bss._ZN1AIiE1aE,"awG",%nobits,_ZN1AIiE1aE,comdat
> .align 2
> - .type _ZN1AIiE1aE, %object
> + .type _ZN1AIiE1aE, %gnu_unique_object
> .size _ZN1AIiE1aE, 4
> .space 4
> and the same for f2.s, regenerating by hand libf1.so and libf2.so and the output
> generated is :
> (natty)lp-ramana at jenipapo:~/cpp_unique_global$ LD_LIBRARY_PATH=.
> f1 0x40028034
> f2 0x40028034
thanks for the analysis. I have filed:
for this issue.
More information about the linaro-toolchain