Re: Is detecting endianness at compile-time unworkable?

From: Michael Felt <aixtools@felt.demon.nl>
Date: Jul 31, 2018, 10:06 UTC
Message-ID: <599fc1eb-d295-fe63-4d86-168d569c876c@felt.demon.nl>
In-Reply-To: <CADMpRy7f_Zr7Ay7bU_5eBS+7yO-58EVsEGE0k9qxefS-TO+z8w@mail.gmail.com>

I have just replied to https://github.com/cr-marcstevens/sha1collisiondetection/pull/42

I checked a gcc compiler on AIX, and I have the defines for vac.

I do not have access yet to SLES or RHEL (or Ubuntu), just a "free Debian" on my Power6.

* my conclusions|recommendations:

a) AIX is always Big Endian, the define _AIX can be used to determine if AIX

b) POWER7 and earlier are always Big Endian

c) assuming lscpu is always available on Linux systems a command (in configure?) could be used:

root@x074:/usr/bin# lscpu | grep -i endian Byte Order: Big Endian

d) some linux systems (in any case latest versions of RHEL and SLES enterprise) should have a file named lparcfg in /proc (/proc/{powerppc|ppc64|ppc64le|ppc64el}/lparcfg - and it might be in that file. Need to get onto a (POWER8|POWER9) system to check.

Hope this helps:

details re: define of _AIX

root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep AIX | head -1 #define _AIX 1

michael@x071:[/home/michael]/usr/bin/grep -p DEFLT: 
/etc/vac.cfg.[567][123] | grep options\
         options   = 
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_IBMR2,-D_POWER
         options   = 
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_IBMR2,-D_POWER
         options   = 
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_IBMR2,-D_POWER
         options   = 
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_AIX72,-D_IBMR2,-D_POWER

michael@x071:[/home/michael]ls /etc/vac.cfg.[567][123] /etc/vac.cfg.53 /etc/vac.cfg.61 /etc/vac.cfg.71 /etc/vac.cfg.72

On 7/30/2018 8:39 PM, Daniel Shumow wrote:

Show 37 quoted lines

> The change was definitely made for performance. Removing the if 
> statements, conditioned upon endianess was an approx 10% improvement, 
> which was very important to getting this library accepted into git.
>
> Thanks,
> Dan
>
>
> On Mon, Jul 30, 2018 at 11:32 AM, Junio C Hamano <gitster@pobox.com 
> <mailto:gitster@pobox.com>> wrote:
>
>     Junio C Hamano <gitster@pobox.com <mailto:gitster@pobox.com>> writes:
>
>     > Ævar Arnfjörð Bjarmason <avarab@gmail.com
>     <mailto:avarab@gmail.com>> writes:
>     >
>     >> And, as an aside, the reason we can't easily make it better
>     ourselves is
>     >> because the build process for git.git doesn't have a facility
>     to run
>     >> code to detect this type of stuff (the configure script is always
>     >> optional). So we can't just run this test ourselves.
>     >
>     > It won't help those who cross-compile anyway.  I thought we declared
>     > "we make a reasonable effort to guess the target endianness from the
>     > system header by inspecting usual macros, but will not aim to cover
>     > every system on the planet---instead there is a knob to tweak it for
>     > those on exotic platforms" last time we discussed this?
>
>     Well, having said all that, I do not think I personally mind if
>     ./configure learned to include a "compile small program and run it
>     to determine byte order on the build machine" as part of "we make a
>     reasonable effort" as long as it cleanly excludes cross building
>     case (and the result is made overridable just in case we misdetect
>     the "cross-ness" of the build).
>
>