[oe] [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]

Robert Schuster thebohemian at gmx.net
Thu Jun 17 07:17:28 UTC 2010


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
>>> Openembedded-devel at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>>     
>>>       
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>   
>>     
>
>   
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100617/9e0cc2d1/attachment-0002.sig>


More information about the Openembedded-devel mailing list