[omniORB] Issue transfering double over the network on x86_64/arvm8

[Duncan Grisby]

On Thu, 2023-02-02 at 20:25 +0100, Thomas Braun via omniORB-list wrote:


> in cppTango we have a report of something going wrong on the armv8
> (Apple M1) platform [1]. It looks like some endianess issue although
> the platform is actually little-endian.
> 
> I suceeded in replicating the issue with an x86_64 server and an
> armv8
> client using src/examples/anyExample. I've compiled omniORB 4.2.5 on
> MacOSX Ventura and debian bullseye.
> 
> See the garbage output for double on the server.

Some ARM CPUs have a strange "mixed-endian" double format, where the
64-bit value is represented as two 32-bit words. The bytes in the 32-
bit words are little endian, but the two 32-bit words are in big endian
order.

I don't think the M1/M2 processors do that bizarre thing, but it looks
as though omniORB's build thinks they do, and so rearranges the values
incorrectly.

If you look in include/omniORB4/CORBA_sysdep.h you'll see this:


// __VFP_FP__ means that the floating point format in use is that of the ARM 
// VFP unit, which is native-endian IEEE-754.
#if defined(__arm__)
#  if defined(__armv5teb__) || defined(__VFP_FP__)
#    define NO_OMNI_MIXED_ENDIAN_DOUBLE
#  else
#    define OMNI_MIXED_ENDIAN_DOUBLE
#  endif
#endif


I would have hoped that __VFP_FP__ was defined in Apple's compiler, but
this would suggest that it is not. I can check what is defined on an M1
system later today, but if you want to look sooner, that is the place
to check.

Duncan.


-- 
Duncan Grisby <duncan at grisby.org>