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@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@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
