i2pd: PowerPC: i2pd fails with Bus error if built using GCC atomics

Thanks, this will help.

In that case adding of -DBOOST_SP_USE_STD_ATOMIC won’t be problem at all. FindArch.cmake can be used to do same check for __POWERPC__ as it has been done for pthread_setname_np and setting of this define for PPC only.

I used g++ initially, built it manually using old Xcode.

I don’t think these old threads have anything to do with the problem. It looks like the spinlock doesn’t work for some reason, but it’s hard to tell why. The first thing to do would probably be to run the Boost.SmartPtr tests, in particular these testing the spinlock:

https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_test.cpp https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_try_test.cpp https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_mt_test.cpp https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_pool_test.cpp https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_pool_mt_test.cpp

Defining the macro BOOST_SP_REPORT_IMPLEMENTATION before compiling any of these should print which spinlock implementation is being used; under a recent GCC it should be this one:

https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/detail/spinlock_gcc_atomic.hpp

I don’t see anything that could be wrong about it specifically on PowerPC.

Definitely boost::atomic is wrong on PPC. Try to write some test example reproducing the problem. No, you can’t disable boost in i2pd, because it’s everywhere.

Most likely #0 0x000c2304 in boost::detail::spinlock::lock ()

comes from this line boost::atomic_store (&m_Addresses, addresses);

try to replace it by m_Addresses = addresses;

If it helps than it’s a boost’s issue

most folks reading this do not understand Russian 😉 … if possible, please use English

(on all OS versions, it’s not a ‘legacy’ difference - the only legacy case is < 10.6 which does not have pthread_setname_np at all)

AFAIR, in that Ruby PR we found out that no_pthread_threadid_np is not supported even on Rosetta. It seems that pthread_setname_np does not err out on either 10.6 PPC or Rosetta, but I am not sure if it does anything.

But we can make a fallback of do nothing for <10.6 instead of PPC then. Will take care of old Intel systems too.

I think you have to remember that Rosetta (1) is not “10.6 PPC” it is a way to run 10.5 ppc exes on intel 10.6 (and 10.5) … so AFAICT it only supports the same interfaces as 10.5.

So I would say that the configuration should expect no pthread_threadid_np() on < 10.6 intel and <= 10.6 ppc.

FWIW, I did patch GDB-7.3.1 (upstream) to work at least on Darwin9 - but it seems that was before I was on github, so it has never been pushed anywhere …

… after GCC-12 branches, I’ll look into finding the patches and pushing them - although TBH the debug experience is still “poor at best” with GDB 7 and modern C++ (although it can help to build the dsymutil from the llvm-7.1.1 branch since that’s more stable with modern DWARF).

It is Yet Another Time Soaking Project to improve native debug on powerpc-darwin 😉

Note that TenFourFox GDB is not based on GDB 7. Rather it’s based on GDB 6.3.50 Apple revision 768. The MacPorts gdb-apple is based on GDB 6.3.50 Apple revision 1824. Enjoy.

@evanmiller Re your gdb-apple, I tried building it, but it fails on 10.6 PPC, both with gcc-4.2 and macports-gcc-10. I cannot file a ticket for that in Macports, but maybe you could take a quick look into it? Having gdb fixed will be quite helpful. main_gdb.log.zip

UPD. I got an idea, maybe I should amend patch-macoxs-tdep.c.diff. Let me try. UPD2. Nah, still fails on macosx-nat-dyld.c. UPD3. Okay, there is the reason: all_image_info_size and all_image_info_addr are available 10.6+ and apparently still missing on 10.6 PPC: https://developer.apple.com/documentation/kernel/task_dyld_info_data_t/1553256-all_image_info_addr https://developer.apple.com/documentation/kernel/task_dyld_info_data_t/1553195-all_image_info_size Now I wonder how it did not fail on 10.5.8 for you, since macosx-nat-dyld.c gives >= 1050 condition for that code section.

I personally tested only on 10.4 and 10.6. It’s possible that it doesn’t compile on 10.5. For your use case, try changing to 1070 in that line or in the corresponding patch here:

https://github.com/macports/macports-ports/blob/master/devel/gdb-apple/files/patch-gdb-availability.diff#L66

Cameron built gdb7 for PPC Tiger and put it here, so that can work

https://sourceforge.net/projects/tenfourfox/files/tools/

@evanmiller was working on gdb for PPC last year and got something going. I forget just now where he got to, or how to get it. Perhaps he’ll remind us if we ask.

My work was merged into the gdb-apple port. Works fine on Tiger but possible missing some newer C++ stuff.

Edit: here’s the PR from last year: https://github.com/macports/macports-ports/pull/11690

Note that TenFourFox GDB is not based on GDB 7. Rather it’s based on GDB 6.3.50 Apple revision 768. The MacPorts gdb-apple is based on GDB 6.3.50 Apple revision 1824. Enjoy.

that symbol comes from libgcc{_s} - so maybe you do not have the right version of libgcc installed?

Cameron built gdb7 for PPC Tiger and put it here, so that can work

https://sourceforge.net/projects/tenfourfox/files/tools/

@evanmiller was working on gdb for PPC last year and got something going. I forget just now where he got to, or how to get it. Perhaps he’ll remind us if we ask.

@iains Ah, so even it builds, it won’t be of any use? (It did build in fact but failed oddly at destroot stage.)

I would suggest to use the GDB from Xcode - trying to build and install a new GDB for powerpc-darwin is creating a second set of problems to solve, it is likely to be a deep rabbit hole 😉

it is not a compiler bug, but the problem we have with 10.5’s dyld not dealing with two copies of libstdc++.dylib …

… I have a solution in mind - but not going to be available this weekend.

@kencu By the way do you know how to force Cmake build system find boost within Macports? I tried adding -DBOOST_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include in portfile and it has no effect: https://trac.macports.org/ticket/64757

I would suggest you try using the boost Portgroup:

https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/boost-1.0.tcl

@r4sas I have tried now to build the latest version of i2pd on 10.5.8, and it still fails:

[ 75%] Building CXX object CMakeFiles/libi2pd.dir/Users/svacchanda/Dev/i2pd/i2pd/libi2pd/util.cpp.o
/Users/svacchanda/Dev/i2pd/i2pd/libi2pd/util.cpp: In function ‘void i2p::util::SetThreadName(const char*)’:
/Users/svacchanda/Dev/i2pd/i2pd/libi2pd/util.cpp:127:17: error: ‘pthread_setname_np’ was not declared in this scope; did you mean ‘pthread_setugid_np’?
  127 |                 pthread_setname_np((char*)name);
      |                 ^~~~~~~~~~~~~~~~~~
      |                 pthread_setugid_np
make[2]: *** [CMakeFiles/libi2pd.dir/Users/svacchanda/Dev/i2pd/i2pd/libi2pd/util.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/libi2pd.dir/all] Error 2
make: *** [all] Error 2

I used this config line: cmake -DCMAKE_C_COMPILER=/opt/svacchanda/gcc11/bin/gcc -DCMAKE_CXX_COMPILER=/opt/svacchanda/gcc11/bin/g++ -DCMAKE_CXX_OSX_DEPLOYMENT_TARGET_FLAG="-mmacosx-version-min=10.5" -DBoost_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include

@barracuda156 – can you sort out how to fix that, and perhaps provide this nice fellow with a PR?

I suggest you consider using something like this:

#if defined(__APPLE__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060

--troublesome code goes here -- 

#endif

but up to you!

The powerpc test will usually work by coincidence – but the way this is usually done is different.

The best way to do this is to test for the function during configure and use it if it exists, of course.

Barring that, compilers including gcc on Apple comes with preset compiler defines that are often used for this, for example:

#if defined(__APPLE__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060

That assumes that there has been no work done to provide that function on such systems, which may not be the case, but anyway is close enough for government work, as we say.

There are also fancier ways of testing and falling back, which have changed over the years and I won’t go into them here now.

I have already added commit to skip pthread naming when __powerpc__ defined (see https://github.com/PurpleI2P/i2pd/commit/73e572b66bd5b233dbbf15cadf3256a8bb98f733), because gcc can’t check OS version, and trying to get it using calls to system isn’t good idea.

@r4sas Above was on 10.6 PPC (10A190).

On a stock 10.5.8 however the build fails as before with:

/Users/svacchanda/i2pd/libi2pd/util.cpp: In function ‘void i2p::util::SetThreadName(const char*)’:
/Users/svacchanda/i2pd/libi2pd/util.cpp:127:17: error: ‘pthread_setname_np’ was not declared in this scope; did you mean ‘pthread_setugid_np’?
  127 |                 pthread_setname_np((char*)name);
      |                 ^~~~~~~~~~~~~~~~~~
      |                 pthread_setugid_np
make[2]: *** [CMakeFiles/libi2pd.dir/Users/svacchanda/i2pd/libi2pd/util.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/libi2pd.dir/all] Error 2
make: *** [all] Error 2

In either case gcc11 was used and Boost 1.76.

@r4sas Above was on 10.6 PPC (10A190).

On a stock 10.5.8 however the build fails as before with:

/Users/svacchanda/i2pd/libi2pd/util.cpp: In function ‘void i2p::util::SetThreadName(const char*)’:
/Users/svacchanda/i2pd/libi2pd/util.cpp:127:17: error: ‘pthread_setname_np’ was not declared in this scope; did you mean ‘pthread_setugid_np’?
  127 |                 pthread_setname_np((char*)name);
      |                 ^~~~~~~~~~~~~~~~~~
      |                 pthread_setugid_np

pthread_setname_np() is not available until 10.6.x where x might == 8 (I have only that to check). So you would need to find an alternative or omit the functionality for earlier OS versions. (nothing to do with the compiler here - although perhaps the configuration).

…