ARM thumb support in spinlock_gcc_arm.hpp

Hi, I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk. I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode. The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead. But has anyone addressed spinlock support for armv6 thumb? Thanks, Jerry

Jerry Napoli wrote:
I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk.
I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode. The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead. But has anyone addressed spinlock support for armv6 thumb?
Sorry this is not an answer but why are you using thumb? Does the iphone sdk force it? While working on armv5 cell phone projects I found that in practice arm was smaller and faster than thumb because many arm instructions took more than 2 thumb instructions to emulate. Thanks, Michael Marcin

Hi Michael, Yes, the sdk forces thumb under the covers. All of the objects provided with the sdk are built with thumb. Thanks, Jerry Michael Marcin wrote:
Jerry Napoli wrote:
I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk.
I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode. The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead. But has anyone addressed spinlock support for armv6 thumb?
Sorry this is not an answer but why are you using thumb? Does the iphone sdk force it?
While working on armv5 cell phone projects I found that in practice arm was smaller and faster than thumb because many arm instructions took more than 2 thumb instructions to emulate.
Thanks,
Michael Marcin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Jerry Napoli:
Yes, the sdk forces thumb under the covers. All of the objects provided with the sdk are built with thumb.
Out of curiosity, have you tried using ARM mode? I remember Rene Rivera posting iPhone test results (no longer present though) and the spinlock tests did pass... unless I'm misremembering things.
From what I read, it's supposedly possible to link ARM and Thumb objects together, not that I've ever tried, of course. :-)

Peter Dimov wrote:
Jerry Napoli:
Yes, the sdk forces thumb under the covers. All of the objects provided with the sdk are built with thumb.
Out of curiosity, have you tried using ARM mode? I remember Rene Rivera posting iPhone test results (no longer present though) and the spinlock tests did pass... unless I'm misremembering things.
You remember correctly... Exceptions didn't work at the time so many tests where useless. Exceptions work now, but I haven't found a way to do remote test execution. Hence no tests are available. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Jerry Napoli wrote:
I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk.
I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode.
I haven't checked, but I can believe that.
The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead.
That is probably the simplest approach if you are not doing anything that makes significant use of locking. Do you know what macros spinlock.hpp should test to determine ARM vs. Thumb mode? There is some magic rune that makes gcc dump all of the pre-defined macros; maybe you could do that and grep for something thumb-related. Otherwise, I think you need to get it to compile that function in non-thumb mode and ensure that all of the callers are in "interworking" mode. I have no idea how that copes with inlining though. It would not be good to break inlining on non-thumb platforms. Another thought: does whatever processor you have in the iphone have the new compare-and-swap instructions? Regards, Phil.

Jerry Napoli:
Hi,
I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk.
I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode. The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead.
I assume you mean spinlock_nt.hpp? Unless someone comes up with a better solution, we probably need to replace #if defined(__GNUC__) && defined( __arm__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) # include <boost/detail/spinlock_sync.hpp> with #if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) && !defined( __arm__ ) # include <boost/detail/spinlock_sync.hpp> Does this change help?

I assume you mean spinlock_nt.hpp?
No, spinlock_pt.hpp. The darwin os on iPhone supports pthreads so this works.
Unless someone comes up with a better solution, we probably need to replace
#if defined(__GNUC__) && defined( __arm__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) # include <boost/detail/spinlock_sync.hpp>
with
#if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) && !defined( __arm__ ) # include <boost/detail/spinlock_sync.hpp>
Does this change help?
Yes, this is perfect. Thanks!
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, Sep 6, 2008 at 3:45 AM, Jerry Napoli <jnapoli@iteamsolutions.com> wrote:
I assume you mean spinlock_nt.hpp?
No, spinlock_pt.hpp. The darwin os on iPhone supports pthreads so this works.
Unless someone comes up with a better solution, we probably need to replace
#if defined(__GNUC__) && defined( __arm__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) # include <boost/detail/spinlock_sync.hpp>
with
#if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ ) # include <boost/detail/spinlock_gcc_arm.hpp> #elif defined(__GNUC__) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 401 ) && !defined( __arm__ ) # include <boost/detail/spinlock_sync.hpp>
Does this change help?
Yes, this is perfect. Thanks!
I hit the same problem today, and googled my way to this thread. Suggestion works perfectly - thanks. Does anyone know if this modification, or something similar, is going to be/ has been committed to the main line (I just have my own locally patched copy for now)? Thanks and regards, [)o IhIL..

Phil Nash:
Does anyone know if this modification, or something similar, is going to be/ has been committed to the main line (I just have my own locally patched copy for now)?
This is ticket #2310: http://svn.boost.org/trac/boost/ticket/2310 fixed in [48834] in trunk: http://svn.boost.org/trac/boost/changeset/48834 and in [48989] in release: http://svn.boost.org/trac/boost/changeset/48989 You can look at the revision history of a particular file by using: http://svn.boost.org/trac/boost/log/trunk/boost/detail/spinlock.hpp

Hi, when trying to compile boost.python using python 2.5.2 (amd64) and Visual Studio 9 the following linker errors occur. I found out that the symbols are really missing from the python25.lib while they are present in the 32bit version. So i think this can be a problem of python. When searching the web i found that this problem is known but no action are taken till now. The python 2.6 rc2 also has the same problem. Here the errors (shortened): ...updating 5 targets... msvc.link.dll e:\devel\_ext\boost_out_64\out\boost\bin.v2\libs\python\build\msvc-9.0_64\release\threading-multi\boost_python-vc90-mt-1_36.dll Creating library e:\devel\_ext\boost_out_64\out\boost\bin.v2\libs\python\build\msvc-9.0_64\release\threading-multi\boost_python-vc90-mt-1_36.lib an d object e:\devel\_ext\boost_out_64\out\boost\bin.v2\libs\python\build\msvc-9.0_64\release\threading-multi\boost_python-vc90-mt-1_36.exp function.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Format referenced in function "void __cdecl boost::python::numeric::`anonymous na mespace'::throw_load_failure(void)" (?throw_load_failure@?A0x4c737783@numeric@python@boost@@YAXXZ) from_python.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format registry.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2019: unresolved external symbol __imp__PyExc_ImportError referenced in function "void __cdecl boost::python::numeric::`anonymo us namespace'::throw_load_failure(void)" (?throw_load_failure@?A0x4c737783@numeric@python@boost@@YAXXZ) enum.obj : error LNK2001: unresolved external symbol __imp__PyEval_CallFunction class.obj : error LNK2001: unresolved external symbol __imp__PyEval_CallFunction Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group

on Sun Sep 28 2008, Christopher Lux <christopherlux-AT-gmail.com> wrote:
Hi, when trying to compile boost.python using python 2.5.2 (amd64) and Visual Studio 9 the following linker errors occur. I found out that the symbols are really missing from the python25.lib while they are present in the 32bit version. So i think this can be a problem of python. When searching the web i found that this problem is known but no action are taken till now. The python 2.6 rc2 also has the same problem.
Here the errors (shortened):
Hi Christopher, Did you ever get this resolved? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Sun Sep 28 2008, Christopher Lux <christopherlux-AT-gmail.com> wrote:
Hi, when trying to compile boost.python using python 2.5.2 (amd64) and Visual Studio 9 the following linker errors occur. I found out that the symbols are really missing from the python25.lib while they are present in the 32bit version. So i think this can be a problem of python. When searching the web i found that this problem is known but no action are taken till now. The python 2.6 rc2 also has the same problem.
Hi Christopher, Did you ever get this issue resolved? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (8)
-
Christopher Lux
-
David Abrahams
-
Jerry Napoli
-
Michael Marcin
-
Peter Dimov
-
Phil Endecott
-
Phil Nash
-
Rene Rivera