Problem running updated compiz branches on ARM

[Alexandros Frantzis]

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
>  _ZN1AIiE1aE:
>         .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=.
> ./main
> f1 0x40028034
> f2 0x40028034
> 
> 
> 
> regards,
> Ramana

Hi Ramana,

thanks for the analysis. I have filed:

https://bugs.launchpad.net/gcc-linaro/+bug/949805

for this issue.

Thanks,
Alexandros