Hi, just a few more words about the patches: - Ubuntu ARM used it for a long time, so its tested for a while - for x86/amd64 atomic operations intrinsics are available for a looong time, so all packages built for these arches where already under the effect of 'GCC atomic builtins are available'.
Regards, Robert Am 17.06.2010 09:09, schrieb Robert Schuster: > Hi, > first of all. As Stefan pointed out the change was needed while working > for Buglabs on OpenJDK support. So it was decided that the introduction > of the mentioned GCC change is handled by Stefan Schmidt now. > > But I would like to elaborate on the side-effects of the patch. > > Am 16.06.2010 19:12, schrieb Khem Raj: > >> Those applications are working fine and they will keep working fine as >> long as you dont recompile them >> and you make sure that libgcc is updated then whenever you rebuild an >> application that uses the atomic >> builtins will start using them until then it should work without using them. >> >> > Yes, already built and shipped applications are not affected at all. > It is only that when certain packages are built again with the new GCC, > the package's binary > will be different although PR (and PV) did not change. The reason is > that most configure scripts check > for the availability of the GCC intrinsics. If they are found they make > use of it, if not they either use a different implementation > (libatomic-ops for example) > or bring their own (software running on ARM Linux 2.6 can assume that > the neccessary kernel helpers exist and make use of them[0]) or silently > disable > multithread support (that is the case for llvm 2.7). > > And already compiled software will also not magically pick up the > implementation found in libgcc because: > 1) it was not there before > 2) I am under the impression that at least some of the builtins are > actually macros and thus bits of machinecode are copied into each binary > using them. > > However as said. Stefan is now dealing with the issue. He has gotten two > patches (one from Ubuntu, another one from the GCC 4.4 stable branch) > that we needed to get things going and is most likely checking the > effects they have. > > Regards, > Robert > > [0] - code like this can be found in many projects; search for > __kernel_dmb and __kernel_cmpxchg: > http://code.google.com/p/nativeclient/source/browse/trunk/src/native_client/src/include/linux/arm/atomic_ops.h?r=857 > >> Maybe I am missing something it would be helpful if Robert could >> explain potential scenarios >> where it would break precompiled binaries. I don't see it. >> >> >> >>> Graeme >>> >>> _______________________________________________ >>> Openembedded-devel mailing list >>> [email protected] >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >>> >>> >>> >> _______________________________________________ >> Openembedded-devel mailing list >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> >> > > > > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
