[omniORB] Incorrect processor define on Apple M1

[Thomas Braun]

Am 15.04.2023 um 13:50 schrieb Duncan Grisby:
> On Fri, 2023-04-14 at 12:36 +0200, Thomas Braun via omniORB-list
> wrote:

Thanks for the quick reply,

> > we do have some issues on cppTango, which uses omniORB, with
> > obvious
> > crashes on Apple M1.
> > 
> > The problem seems to be that the omniORB pkg-config files use the
> > wrong processor defines.
> 
> [...]
> > and that gives
> > 
> > PROCESSOR_DEFINE='__arm__'
> > PROCESSOR_NAME='ArmProcessor'
> 
> I agree that it is not quite right. However, I am not sure how that
> could lead to a crash. The only place in omniORB that actually looks
> at
> that processor define is where it handles the old ARM mixed-endian
> double format. It certainly could become confused and break double
> precision values, which would clearly be bad, but it would not crash.
> 
> Or is it that the definition of __arm__ somehow breaks some other
> code
> that is not in omniORB?

Yes this is the problem. PROCESSOR_DEFINE is used in 
contrib/pkgconfig/omnithread.pc.in and include/omniconfig.h.in.

clang -print-target-triple says

arm64-apple-darwin22.3.0

and if I then check what it defines for architecture arm64 with

clang -arch arm64 -dM -E - < /dev/null | grep -e __aarch -e __arm

I get

#define __aarch64__ 1
#define __arm64 1
#define __arm64__ 1

and checking for plain arm gives

clang -arch arm -dM -E - < /dev/null | grep -e __aarch -e __arm 
#define __arm 1
#define __arm__ 1

[2] hints also to the fact that __arm__ should be only defined for
32bit arm.

Grepping through some system files gives

grep -A3 __arm__
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xcto
olchain/usr/include/c++/v1/__threading_support
#if defined(_M_IX86) || defined(__i386__) || defined(_M_ARM) ||
defined(__arm__)
typedef void* __libcpp_recursive_mutex_t[6];
#elif defined(_M_AMD64) || defined(__x86_64__) || defined(_M_ARM64) ||
defined(__aarch64__)
typedef void* __libcpp_recursive_mutex_t[5];

which gives the same conclusion.

To summarize:
PROCESSOR_DEFINE should be __aarch64__ on Apple M1 as that is what
clang defines by default.

> If the crash is in omniORB, can you give a stack trace for it?

What we see are random SIGABORT when deallocating std::string objects.
The fix was to *not* use the pkg-config file supplied with omniORB.
That was how we found the __arm__ define. I'm attaching the lldb output
of one of those crashes.

[2]: https://stackoverflow.com/a/41666292

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigabrt.trace.gz
Type: application/gzip
Size: 2430 bytes
Desc: not available
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20230415/b64d0d09/attachment.gz>