M68K-Coldfire: Boost 1.44 seems to have a problem with low level locking
Hello, I recently upgraded boost on my embedded linux platform (m68k coldfire architecture) from version 1.41 (cmake release) to 1.44. Boost itself compiles flawlessly but when I tried to link my application (which makes use of the thread, regex, system libraries) it fails with (note the last line): squ_loopback_timer.o: In function `boost::asio::detail::wait_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, rapp::squ_loopback_timer_t, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<rapp::squ_loopback_timer_t*>, boost::arg<1> > >
::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned int)': squ_loopback_timer.cpp:(.text._ZN5boost4asio6detail12wait_handlerINS_3_bi6bind_tIvNS_4_mfi3mf1IvN4rapp20squ_loopback_timer_tERKNS_6system10error_codeEEENS3_5list2INS3_5valueIPS8_EENS_3argILi1EEEEEEEE11do_completeEPNS1_15task_io_serviceEPNS1_25task_io_service_operationESA_j[boost::asio::detail::wait_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, rapp::squ_loopback_timer_t, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<rapp::squ_loopback_timer_t*>, boost::arg<1> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned int)]+0x72): undefined reference to `__sync_lock_test_and_set_4'
What changed about the locking mechanism? Btw. I'm also using boost version 1.38 in another project (but on the same platform). My compiler is g++ version 4.2.0 20070318 (prerelease) (Sourcery G++ Lite 4.2-35). Any hints or help is appreciated! Best regards -- Dipl.-Ing. (FH) Andreas Wehrmann Software Development -------------------------------------------------------------- Center Communication Systems GmbH A-1210 Wien, Ignaz-Köck-Straße 19 Sitz in Wien FN 796 88p, Firmenbuchgericht Wien www.centersystems.com Tel.: +43 (0) 190 199 - 3616 Mobile: +43 (0) 664 884 75916 Fax: +43 (0) 190 199 - 2110 E-Mail: a.wehrmann@centersystems.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Andreas Wehrmann wrote:
Hello,
I recently upgraded boost on my embedded linux platform (m68k coldfire architecture) from version 1.41 (cmake release) to 1.44. Boost itself compiles flawlessly but when I tried to link my application (which makes use of the thread, regex, system libraries) it fails with (note the last line):
squ_loopback_timer.o: In function `boost::asio::detail::wait_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, rapp::squ_loopback_timer_t, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<rapp::squ_loopback_timer_t*>, boost::arg<1> > >
::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned int)': squ_loopback_timer.cpp: (.text._ZN5boost4asio6detail12wait_handlerINS_3_bi6bind_tIvNS_4_mfi3mf1IvN4rapp20squ_loopback_timer_tERKNS_6system10error_codeEEENS3_5list2INS3_5valueIPS8_EENS_3argILi1EEEEEEEE11do_completeEPNS1_15task_io_serviceEPNS1_25task_io_service_operationESA_j[boost::asio::detail::wait_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, rapp::squ_loopback_timer_t, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<rapp::squ_loopback_timer_t*>, boost::arg<1> > > ::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned int)]+0x72): undefined reference to `__sync_lock_test_and_set_4'
What changed about the locking mechanism?
Boost is now using gcc atomics, but it assumes them to be available everywhere, which is not the case. Adding define=BOOST_SP_DISABLE_THREADS or define=BOOST_SP_USE_PTHREADS to build command should fix this error (at the price of either thread safety or performance)
Btw. I'm also using boost version 1.38 in another project (but on the same platform). My compiler is g++ version 4.2.0 20070318 (prerelease) (Sourcery G++ Lite 4.2-35).
That's pretty old compiler, our current lite releases are 4.4-*. However, upgrading is not likely to fix your immediate issue. - Volodya
Boost is now using gcc atomics, but it assumes them to be available everywhere, which is not the case. Adding
define=BOOST_SP_DISABLE_THREADS
or
define=BOOST_SP_USE_PTHREADS
to build command should fix this error (at the price of either thread safety or performance)
I tried BOOST_SP_USE_PTHREADS and BOOST_SP_USE_SPINLOCK of which neither one works. I am not willing to pay the price for losing thread safety, which is why I haven't tried the other define.
Btw. I'm also using boost version 1.38 in another project (but on the same platform). My compiler is g++ version 4.2.0 20070318 (prerelease) (Sourcery G++ Lite 4.2-35). That's pretty old compiler, our current lite releases are 4.4-*. However, upgrading is not likely to fix your immediate issue.
- Volodya
I know, we upgraded to the 4.4 version once and had nothing but problems which is why we reverted to 4.2. Thanks for your hints thus far, do you have any idea of why BOOST_SP_USE_PTHREADS doesn't work? I've seen that where we're using boost 1.38 it is being compiled with that define set in user.hpp but for 1.41 it is not... Best regards -- Dipl.-Ing. (FH) Andreas Wehrmann Software Development -------------------------------------------------------------- Center Communication Systems GmbH A-1210 Wien, Ignaz-Köck-Straße 19 Sitz in Wien FN 796 88p, Firmenbuchgericht Wien www.centersystems.com Tel.: +43 (0) 190 199 - 3616 Mobile: +43 (0) 664 884 75916 Fax: +43 (0) 190 199 - 2110 E-Mail: a.wehrmann@centersystems.com
Andreas Wehrmann wrote:
Thanks for your hints thus far, do you have any idea of why BOOST_SP_USE_PTHREADS doesn't work? I've seen that where we're using boost 1.38 it is being compiled with that define set in user.hpp but for 1.41 it is not...
Your error isn't caused by shared_ptr, but by ASIO's "fenced block" in boost/asio/detail/fenced_block.hpp and boost/asio/detail/gcc_sync_fenced_block.hpp. I've no idea what this "fenced block" is supposed to do - it seems to insert or try to insert memory barriers - but on M68K, it should be safe to disable it via BOOST_ASIO_DISABLE_FENCED_BLOCK.
Hello! That did it indeed! Adding the define for BOOST_ASIO_DISABLE_FENCED_BLOCK to boost/config/user.hpp seems to have solved the problem, the application now links without problems. I'll let you know when it causes any problems. Thanks, Andreas On 09/15/2010 11:03 AM, Peter Dimov wrote:
Andreas Wehrmann wrote:
Thanks for your hints thus far, do you have any idea of why BOOST_SP_USE_PTHREADS doesn't work? I've seen that where we're using boost 1.38 it is being compiled with that define set in user.hpp but for 1.41 it is not...
Your error isn't caused by shared_ptr, but by ASIO's "fenced block" in boost/asio/detail/fenced_block.hpp and boost/asio/detail/gcc_sync_fenced_block.hpp. I've no idea what this "fenced block" is supposed to do - it seems to insert or try to insert memory barriers - but on M68K, it should be safe to disable it via BOOST_ASIO_DISABLE_FENCED_BLOCK. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Dipl.-Ing. (FH) Andreas Wehrmann Software Development -------------------------------------------------------------- Center Communication Systems GmbH A-1210 Wien, Ignaz-Köck-Straße 19 Sitz in Wien FN 796 88p, Firmenbuchgericht Wien www.centersystems.com Tel.: +43 (0) 190 199 - 3616 Mobile: +43 (0) 664 884 75916 Fax: +43 (0) 190 199 - 2110 E-Mail: a.wehrmann@centersystems.com
Andreas Wehrmann wrote:
Boost is now using gcc atomics, but it assumes them to be available everywhere, which is not the case. Adding
define=BOOST_SP_DISABLE_THREADS
or
define=BOOST_SP_USE_PTHREADS
to build command should fix this error (at the price of either thread safety or performance)
I tried BOOST_SP_USE_PTHREADS and BOOST_SP_USE_SPINLOCK of which neither one works. I am not willing to pay the price for losing thread safety, which is why I haven't tried the other define.
Btw. I'm also using boost version 1.38 in another project (but on the same platform). My compiler is g++ version 4.2.0 20070318 (prerelease) (Sourcery G++ Lite 4.2-35). That's pretty old compiler, our current lite releases are 4.4-*. However, upgrading is not likely to fix your immediate issue.
- Volodya
I know, we upgraded to the 4.4 version once and had nothing but problems which is why we reverted to 4.2.
Thanks for your hints thus far, do you have any idea of why BOOST_SP_USE_PTHREADS doesn't work?
What is sgu_loopback_timer.o? If this is your file, it also should be compiled with that define. If you're using 1.38, it might have a bug whereby define=XXX is not respected on the command line. Hacking boost/smart_ptr/detail/sp_counted_base.hpp may be more reliable. I am not entirely sure whether hacking user.hpp will work or not. HTH, Volodya
participants (3)
-
Andreas Wehrmann -
Peter Dimov -
Vladimir Prus