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