* git broken for AIX somewhere between 2.13.2 and 2.13.3 @ 2018-07-29 16:44 Michael 2018-07-29 18:10 ` brian m. carlson 0 siblings, 1 reply; 25+ messages in thread From: Michael @ 2018-07-29 16:44 UTC (permalink / raw) To: git Hi, Several years ago I had downloaded and packaged git-2.10.1 with no real issues, and it has been working fine. Deciding it was time for an update I downloaded git-2.18.0 and built from scratch. After testing lots of version - the the last 2.12 version worked; git-2.13.2 works but git-2.13.3 does not. root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git root@x066:[/tmp/xxx]git --version git version 2.13.2 root@x066:[/tmp/xxx]ls -l total 0 drwxr-xr-x 3 root system 256 Jul 29 16:37 hello-world root@x066:[/tmp/xxx]git --version git version 2.13.3 root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git Cloning into 'hello-world'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 Receiving objects: 100% (3/3), done. fatal: pack is corrupted (SHA1 mismatch) fatal: index-pack failed p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning into ...', which version 2.13.1 did give. I guess a bisect is the next step - between version 2.13.2 and 2.13.3. Other suggestions welcome! Michael ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 16:44 git broken for AIX somewhere between 2.13.2 and 2.13.3 Michael @ 2018-07-29 18:10 ` brian m. carlson 2018-07-29 19:46 ` Michael [not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl> 0 siblings, 2 replies; 25+ messages in thread From: brian m. carlson @ 2018-07-29 18:10 UTC (permalink / raw) To: Michael; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1008 bytes --] On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote: > root@x066:[/tmp/xxx]git --version > git version 2.13.3 > root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git > Cloning into 'hello-world'... > remote: Counting objects: 3, done. > remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 > Receiving objects: 100% (3/3), done. > fatal: pack is corrupted (SHA1 mismatch) > fatal: index-pack failed > > p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning into > ...', which version 2.13.1 did give. > > I guess a bisect is the next step - between version 2.13.2 and 2.13.3. Other > suggestions welcome! Are you using SHA1DC on that system, and does compiling with another SHA-1 implementation help? There was a change to the SHA1DC code big endian detection in that commit, which might be the cause of your problems if you're using a POWER or PowerPC system. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 867 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 18:10 ` brian m. carlson @ 2018-07-29 19:46 ` Michael 2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason [not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl> 1 sibling, 1 reply; 25+ messages in thread From: Michael @ 2018-07-29 19:46 UTC (permalink / raw) To: brian m. carlson, git [-- Attachment #1: Type: text/plain, Size: 3339 bytes --] On 29/07/2018 20:10, brian m. carlson wrote: > On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote: >> root@x066:[/tmp/xxx]git --version >> git version 2.13.3 >> root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git >> Cloning into 'hello-world'... >> remote: Counting objects: 3, done. >> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 >> Receiving objects: 100% (3/3), done. >> fatal: pack is corrupted (SHA1 mismatch) >> fatal: index-pack failed >> >> p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning into >> ...', which version 2.13.1 did give. >> >> I guess a bisect is the next step - between version 2.13.2 and 2.13.3. Other >> suggestions welcome! > Are you using SHA1DC on that system, and does compiling with another > SHA-1 implementation help? There was a change to the SHA1DC code big > endian detection in that commit, which might be the cause of your > problems if you're using a POWER or PowerPC system. I was thinking it might be an 'endian' issue. So, yes - AIX runs on POWER, only as BigEndian. git bisect returns: michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad Bisecting: 1 revision left to test after this (roughly 1 step) [35049a2343948f686861e176a8c395f9f67da7b6] Merge branch 'aw/contrib-subtree-doc-asciidoctor' into maint michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [9936c1b52a39fa14fca04f937df3e75f7498ac66] sha1dc: update from upstream michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad 9936c1b52a39fa14fca04f937df3e75f7498ac66 is the first bad commit commit 9936c1b52a39fa14fca04f937df3e75f7498ac66 Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Sat Jul 1 22:05:45 2017 +0000 sha1dc: update from upstream Update sha1dc from the latest version by the upstream maintainer[1]. See commit 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for the last update. This solves the Big Endian detection on Solaris reported against v2.13.2[2], hopefully without any regressions. A version of this has been tested on two Solaris SPARC installations, Cygwin (by jturney on cygwin@Freenode), and on numerous more boring systems (mainly linux/x86_64). See [3] for a discussion of the implementation and platform-specific issues. See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) and 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for previous attempts in the 2.13 series to address various compile-time feature detection in this library. 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/19d97bf5af05312267c2e874ee6bcf584d9e9681 2. <CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com> (https://public-inbox.org/git/CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com/) 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/34 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> :040000 040000 a84797967fb742e4ca9618a641d53ce3a6c6589b 32efa656d78901da961e4a47d84b6d82fede064b M sha1dc [-- Attachment #2: Type: text/html, Size: 5402 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 19:46 ` Michael @ 2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason 2018-07-29 21:40 ` Andreas Schwab 0 siblings, 1 reply; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-07-29 20:05 UTC (permalink / raw) To: Michael; +Cc: brian m. carlson, git On Sun, Jul 29 2018, Michael wrote: > On 29/07/2018 20:10, brian m. carlson wrote: >> On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote: >>> root@x066:[/tmp/xxx]git --version >>> git version 2.13.3 >>> root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git >>> Cloning into 'hello-world'... >>> remote: Counting objects: 3, done. >>> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 >>> Receiving objects: 100% (3/3), done. >>> fatal: pack is corrupted (SHA1 mismatch) >>> fatal: index-pack failed >>> >>> p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning into >>> ...', which version 2.13.1 did give. >>> >>> I guess a bisect is the next step - between version 2.13.2 and 2.13.3. Other >>> suggestions welcome! >> Are you using SHA1DC on that system, and does compiling with another >> SHA-1 implementation help? There was a change to the SHA1DC code big >> endian detection in that commit, which might be the cause of your >> problems if you're using a POWER or PowerPC system. > > I was thinking it might be an 'endian' issue. So, yes - AIX runs on > POWER, only as BigEndian. > > git bisect returns: > > michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad > Bisecting: 1 revision left to test after this (roughly 1 step) > [35049a2343948f686861e176a8c395f9f67da7b6] Merge branch > 'aw/contrib-subtree-doc-asciidoctor' into maint > michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect good > Bisecting: 0 revisions left to test after this (roughly 0 steps) > [9936c1b52a39fa14fca04f937df3e75f7498ac66] sha1dc: update from upstream > > > michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad > 9936c1b52a39fa14fca04f937df3e75f7498ac66 is the first bad commit > commit 9936c1b52a39fa14fca04f937df3e75f7498ac66 > Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> > Date: Sat Jul 1 22:05:45 2017 +0000 > > sha1dc: update from upstream > > Update sha1dc from the latest version by the upstream maintainer[1]. > > See commit 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for > the last update. > > This solves the Big Endian detection on Solaris reported against > v2.13.2[2], hopefully without any regressions. A version of this has > been tested on two Solaris SPARC installations, Cygwin (by jturney on > cygwin@Freenode), and on numerous more boring systems (mainly > linux/x86_64). See [3] for a discussion of the implementation and > platform-specific issues. > > See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) and > 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for previous > attempts in the 2.13 series to address various compile-time feature > detection in this library. > > > 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/19d97bf5af05312267c2e874ee6bcf584d9e9681 > > > 2. <CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com> > (https://public-inbox.org/git/CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com/) > > 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/34 > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> > Signed-off-by: Junio C Hamano <gitster@pobox.com> > > :040000 040000 a84797967fb742e4ca9618a641d53ce3a6c6589b > 32efa656d78901da961e4a47d84b6d82fede064b M sha1dc Sorry about that. As can be seen from those PRs and the "git log" detecting whether something is big endian or not can be quite tricky, we figured out how to do it on both BSD and Solaris, but apparently broke AIX as a result. You should be able to define -DSHA1DC_FORCE_LITTLEENDIAN or -DSHA1DC_FORCE_BIGENDIAN (looks like you'll need the latter) to get the latest version to compile, but I and upstream cr-marcstevens would be very interested to know from someone who knows AIX how this broke. Also, to you and anyone else with access to AIX: I'd be happy to figure these issues out pro-actively if you give me a login to an AIX machine. I promise not to do anything except compile/debug/test git on it. I used to have access to an AIX box through a previous job ages ago, it's a very interesting OS and like with Solaris it's easy to discover a lot of portability issues. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason @ 2018-07-29 21:40 ` Andreas Schwab 2018-07-30 6:22 ` Michael 0 siblings, 1 reply; 25+ messages in thread From: Andreas Schwab @ 2018-07-29 21:40 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Michael, brian m. carlson, git On Jul 29 2018, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > Also, to you and anyone else with access to AIX: I'd be happy to figure > these issues out pro-actively if you give me a login to an AIX > machine. I promise not to do anything except compile/debug/test git on > it. The GCC compile farm <http://gcc.gnu.org/wiki/CompileFarm> has a machine running AIX, and is free to use for anyone working on free software. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 21:40 ` Andreas Schwab @ 2018-07-30 6:22 ` Michael 0 siblings, 0 replies; 25+ messages in thread From: Michael @ 2018-07-30 6:22 UTC (permalink / raw) To: Andreas Schwab, Ævar Arnfjörð Bjarmason Cc: brian m. carlson, git On 29/07/2018 23:40, Andreas Schwab wrote: > On Jul 29 2018, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > >> Also, to you and anyone else with access to AIX: I'd be happy to figure >> these issues out pro-actively if you give me a login to an AIX >> machine. I promise not to do anything except compile/debug/test git on >> it. > The GCC compile farm <http://gcc.gnu.org/wiki/CompileFarm> has a machine > running AIX, and is free to use for anyone working on free software. My goal is less "to work on", more, "to package" and/or "to work with". Most others, including IBM, seem to use gcc as compiler - which is fine. However, on AIX I often see side-effects introduced by the GNU run-time environment needed on top of the xlc.rte provided as part of AIX. In any case - my testing is using the xlc complier - so there are syntax differences. the compiler has many modes - by default I use 'xlc_r' that has the following default settings: xlc_r: use = DEFLT_C crt = /lib/crt0.o mcrt = /lib/mcrt0.o gcrt = /lib/gcrt0.o libraries = -L/usr/vac/lib,-lxlopt,-lxlipa,-lxl,-lpthreads,-lc proflibs = -L/lib/profiled,-L/usr/lib/profiled hdlibs = -L/usr/vac/lib,-lhmd options = -qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi,-qthreaded,-D_THREAD_SAFE,-D__VACPP_MULTI__ DEFLT_C (for the curious, the default options is perhaps most interesting) is: * common definitions DEFLT_C: use =DEFLT xlurt_cfg_path=/usr/vac/urt xlurt_cfg_name=urt_client.cfg DEFLT_CPP: use =DEFLT xlurt_cfg_path=/usr/vacpp/urt xlurt_cfg_name=urt_client.cfg DEFLT: cppcomp = /usr/vacpp/exe/xlCentry ccomp = /usr/vac/exe/xlcentry code = /usr/vac/exe/xlCcode cpp = /usr/vac/exe/xlCcpp munch = /usr/vacpp/exe/munch dis = /usr/vac/exe/dis xlC = /usr/vac/bin/xlc list = /usr/vac/exe/xllist xslt = /usr/vac/exe/XALAN transforms = /usr/vac/listings listlibs = /usr/vac/lib cppinc = /usr/vacpp/include ipa = /usr/vac/exe/ipa cppfilt = /usr/vacpp/bin/c++filt bolt = /usr/vac/exe/bolt as = /bin/as ld = /bin/ld artool = /bin/ar options = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_IBMR2,-D_POWER options32 = -bpT:0x10000000,-bpD:0x20000000 options32_bmaxdata = -bpT:0x10000000,-bpD:0x30000000 options64 = -bpT:0x100000000,-bpD:0x110000000 ldopt = "b:o:e:u:R:H:Y:Z:L:T:A:k:j:" hdlibs = -L/usr/vac/lib,-lhmd xlCcopt = -qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi crt_64 = /lib/crt0_64.o mcrt_64 = /lib/mcrt0_64.o gcrt_64 = /lib/gcrt0_64.o smplibraries = -lxlsmp palibraries = -L/usr/vatools/lib,-lpahooks resexp = /usr/vacpp/lib/res.exp genexports = /usr/vac/bin/CreateExportList vac_path = /usr/vac vacpp_path = /usr/vacpp xlcmp_path = /usr/vac:/usr/vacpp xlc_c_stdinc = /usr/vac/include:/usr/include xlc_cpp_stdinc = /usr/vacpp/include:/usr/include xlurt_msg_cat_name=vacumsg.cat __GNUC_MINOR__ = 3 > > Andreas. > ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl>]
[parent not found: <20180729192753.GD945730@genre.crustytoothpaste.net>]
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 [not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net> @ 2018-07-29 19:48 ` Michael 2018-07-29 20:06 ` brian m. carlson 0 siblings, 1 reply; 25+ messages in thread From: Michael @ 2018-07-29 19:48 UTC (permalink / raw) To: brian m. carlson; +Cc: git On 29/07/2018 21:27, brian m. carlson wrote: > On Sun, Jul 29, 2018 at 08:59:39PM +0200, Michael wrote: >> On 29/07/2018 20:10, brian m. carlson wrote: >>> Are you using SHA1DC on that system, and does compiling with another >>> SHA-1 implementation help? There was a change to the SHA1DC code big >>> endian detection in that commit, which might be the cause of your >>> problems if you're using a POWER or PowerPC system. >> I was thinking it might be an 'endian' issue. So, yes - AIX runs on POWER, >> only as BigEndian. > Well, that explains it. I would recommend submitting a patch to > https://github.com/cr-marcstevens/sha1collisiondetection, and the we can > pull in the updated submodule with that fix. Not sure I am smart enough to do that. I'll have to download, build, and see what it says. > > In the mean time, you could build using OpenSSL or the block SHA-1 > implementation, and switch back once things are in a good state. I do > recommend using SHA1DC for things long term, though, as attacks on SHA-1 > are only going to get better. Any suggestions on where/how to do this? root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep -i sha --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep ssl --with-openssl use OpenSSL library (default is YES) ARG can be prefix for openssl library and headers ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 19:48 ` Michael @ 2018-07-29 20:06 ` brian m. carlson 2018-07-29 20:50 ` Michael 0 siblings, 1 reply; 25+ messages in thread From: brian m. carlson @ 2018-07-29 20:06 UTC (permalink / raw) To: Michael; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1912 bytes --] On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote: > On 29/07/2018 21:27, brian m. carlson wrote: > > Well, that explains it. I would recommend submitting a patch to > > https://github.com/cr-marcstevens/sha1collisiondetection, and the we can > > pull in the updated submodule with that fix. > Not sure I am smart enough to do that. I'll have to download, build, and see > what it says. The issue is that somewhere in lib/sha1.c, you need to cause SHA1DC_BIGENDIAN to be set. That means you need to figure out what compiler macro might indicate that. I can tell you that a POWER- or PowerPC-specific one is going to be a bad choice unless it includes the endianness, since those chips come in little-endian versions as well. _AIX might be a fine choice if you know that it only ever runs on big-endian chips. > > In the mean time, you could build using OpenSSL or the block SHA-1 > > implementation, and switch back once things are in a good state. I do > > recommend using SHA1DC for things long term, though, as attacks on SHA-1 > > are only going to get better. > Any suggestions on where/how to do this? > > root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep -i > sha > --sharedstatedir=DIR modifiable architecture-independent data > [PREFIX/com] > --datarootdir=DIR read-only arch.-independent data root > [PREFIX/share] > > root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep ssl > --with-openssl use OpenSSL library (default is YES) > ARG can be prefix for openssl library and headers If you're using configure, you can use --with-openssl, or --with-openssl=PREFIX if your OpenSSL isn't in the standard location but is instead in PREFIX. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 867 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3 2018-07-29 20:06 ` brian m. carlson @ 2018-07-29 20:50 ` Michael 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 25+ messages in thread From: Michael @ 2018-07-29 20:50 UTC (permalink / raw) To: brian m. carlson, git On 29/07/2018 22:06, brian m. carlson wrote: > On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote: >> On 29/07/2018 21:27, brian m. carlson wrote: >>> Well, that explains it. I would recommend submitting a patch to >>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can >>> pull in the updated submodule with that fix. >> Not sure I am smart enough to do that. I'll have to download, build, and see >> what it says. > The issue is that somewhere in lib/sha1.c, you need to cause > SHA1DC_BIGENDIAN to be set. That means you need to figure out what > compiler macro might indicate that. I remember - roughly - a few decades back - having an assignment to write code to determine endianness. PDP and VAC were different iirc, and many other micro-processors besides the 8088/8086/z85/68k/etc.. If you are looking for a compiler macro as a way to determine this - maybe you have one for gcc, but not for xlc. I do not know it - currently :) > I can tell you that a POWER- or > PowerPC-specific one is going to be a bad choice unless it includes the > endianness, since those chips come in little-endian versions as well. Actually, the POWER8 and POWER9 (and I expect all future versions) support both. There are not separate chips. Per virtual machine - a mode is determined during boot (virtual power on) e.g., SLES11 only ran in BigEndian and SLES12 only runs in LittleEndian. afaik, RHEL was supplying both BE and LE distributions. AIX, as an OS, only runs in BE mode, and I expect IBM i (was os/400) is also only running in BE. > > _AIX might be a fine choice if you know that it only ever runs on > big-endian chips. Do you mean just testing for _AIX. That would be very very easy - yes! >>> In the mean time, you could build using OpenSSL or the block SHA-1 >>> implementation, and switch back once things are in a good state. I do >>> recommend using SHA1DC for things long term, though, as attacks on SHA-1 >>> are only going to get better. >> Any suggestions on where/how to do this? >> >> root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep -i >> sha >> --sharedstatedir=DIR modifiable architecture-independent data >> [PREFIX/com] >> --datarootdir=DIR read-only arch.-independent data root >> [PREFIX/share] >> >> root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep ssl >> --with-openssl use OpenSSL library (default is YES) >> ARG can be prefix for openssl library and headers > If you're using configure, you can use --with-openssl, or > --with-openssl=PREFIX if your OpenSSL isn't in the standard location but > is instead in PREFIX. I'll look in configure to see if it is not finding openssl. I was assuming it was found - as everything else using GNU "auto" tools find it okay. i.e., /var/lib/libssl.a, etc.. Tomorrow! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Is detecting endianness at compile-time unworkable? 2018-07-29 20:50 ` Michael @ 2018-07-30 9:39 ` Ævar Arnfjörð Bjarmason 2018-07-30 14:54 ` Junio C Hamano ` (3 more replies) 0 siblings, 4 replies; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-07-30 9:39 UTC (permalink / raw) To: Michael; +Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King On Sun, Jul 29 2018, Michael wrote: > On 29/07/2018 22:06, brian m. carlson wrote: >> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote: >>> On 29/07/2018 21:27, brian m. carlson wrote: >>>> Well, that explains it. I would recommend submitting a patch to >>>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can >>>> pull in the updated submodule with that fix. >>> Not sure I am smart enough to do that. I'll have to download, build, and see >>> what it says. >> The issue is that somewhere in lib/sha1.c, you need to cause >> SHA1DC_BIGENDIAN to be set. That means you need to figure out what >> compiler macro might indicate that. > I remember - roughly - a few decades back - having an assignment to > write code to determine endianness. PDP and VAC were different iirc, > and many other micro-processors besides the 8088/8086/z85/68k/etc.. > > If you are looking for a compiler macro as a way to determine this - > maybe you have one for gcc, but not for xlc. I do not know it - currently :) I'm not familiar with AIX, but from searching around I found this porting manual from IBM: http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf There they suggest either defining your own macros, or testing the memory layout at runtime (see section "2.2.2.3 Technique 3: Testing memory layout" and surrounding sections). Perhaps it's worth taking a step back here and thinking about whether this whole thing is unworkable. It was hard enough to get this to work on the combination of Linux, *BSD and Solaris, but I suspect we'll run into increasingly obscure platforms where this is hard or impossible (AIX, HP/UX etc.) The reason we're in this hole is because we use this sha1collisiondetection library to do SHA-1, and the reason we have issues with it specifically (not OpenSSL et al) is because its only method of detecting endianness is at compile time. This didn't use to be the case, it was changed in this commit: https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672 Dan Shumow: Since the commit message doesn't say why, can you elaborate a bit on why this was done, i.e. is determining this at runtime harmful for performance? If not, perhaps it would be best to bring this back, at least as an option. 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. Junio: I've barked up that particular tree before in https://public-inbox.org/git/87a7x3kmh5.fsf@evledraar.gmail.com/ and I won't bore you all by repeating myself, except to say that this is yet another case where I wish we had a hard dependency on some way of doing checks via compiled code in our build system. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason @ 2018-07-30 14:54 ` Junio C Hamano 2018-07-30 18:32 ` Junio C Hamano 2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason 2018-07-31 10:39 ` Michael Felt ` (2 subsequent siblings) 3 siblings, 2 replies; 25+ messages in thread From: Junio C Hamano @ 2018-07-30 14:54 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Michael, brian m. carlson, git, Dan Shumow, Jeff King Ævar Arnfjörð Bjarmason <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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 14:54 ` Junio C Hamano @ 2018-07-30 18:32 ` Junio C Hamano 2018-07-30 18:39 ` Daniel Shumow 2018-08-01 1:35 ` Eric Wong 2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason 1 sibling, 2 replies; 25+ messages in thread From: Junio C Hamano @ 2018-07-30 18:32 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Michael, brian m. carlson, git, Dan Shumow, Jeff King Junio C Hamano <gitster@pobox.com> writes: > Ævar Arnfjörð Bjarmason <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). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 18:32 ` Junio C Hamano @ 2018-07-30 18:39 ` Daniel Shumow 2018-07-31 10:06 ` Michael Felt 2018-08-01 1:35 ` Eric Wong 1 sibling, 1 reply; 25+ messages in thread From: Daniel Shumow @ 2018-07-30 18:39 UTC (permalink / raw) To: Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, Michael, brian m. carlson, git, Jeff King [-- Attachment #1: Type: text/plain, Size: 1454 bytes --] 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> wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Ævar Arnfjörð Bjarmason <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). > > [-- Attachment #2: Type: text/html, Size: 2064 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 18:39 ` Daniel Shumow @ 2018-07-31 10:06 ` Michael Felt 0 siblings, 0 replies; 25+ messages in thread From: Michael Felt @ 2018-07-31 10:06 UTC (permalink / raw) To: Daniel Shumow, Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, brian m. carlson, git, Jeff King [-- Attachment #1: Type: text/plain, Size: 3396 bytes --] 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: > 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). > > [-- Attachment #2: Type: text/html, Size: 5514 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 18:32 ` Junio C Hamano 2018-07-30 18:39 ` Daniel Shumow @ 2018-08-01 1:35 ` Eric Wong 1 sibling, 0 replies; 25+ messages in thread From: Eric Wong @ 2018-08-01 1:35 UTC (permalink / raw) To: Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, Michael, brian m. carlson, git, Dan Shumow, Jeff King Junio C Hamano <gitster@pobox.com> wrote: > 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). No need to run the program for cross-compiles, grepping a object file seems to work for autoconf: git clone https://git.sv.gnu.org/git/autoconf.git $PAGER autoconf/lib/autoconf/c.m4 # look for "BIGenDianSyS" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 14:54 ` Junio C Hamano 2018-07-30 18:32 ` Junio C Hamano @ 2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason 1 sibling, 0 replies; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-08-01 7:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michael, brian m. carlson, git, Dan Shumow, Jeff King On Mon, Jul 30 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <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 was being unclear, what I mean by having "a hard dependency on some way of doing checks via compiled code in our build system" is that we would do some equivalent of this: diff --git a/Makefile b/Makefile index 08e5c54549..b021b6e1b6 100644 --- a/Makefile +++ b/Makefile @@ -1107,7 +1107,7 @@ DC_SHA1_SUBMODULE = auto endif include config.mak.uname --include config.mak.autogen +include config.mak.autogen -include config.mak ifdef DEVELOPER And document that in order to build git you needed to do './configure && make' instead of just 'make', and we'd error out by default if config.mak.autogen wasn't there. Now obviously that would need some sort of escape hatch. I.e. you could invoke 'make' like this: make CONFIGURE_MAK_AUTOGEN_FILE=some-file That's how you would do cross-compilation, you'd arrange to run './configure' on some system, save the output, and ferry over this 'some-file' to where you're building git, or you would manually prepare a file that had all the settings we'd expect to have been set already set. Now, whether we do this with autoconf or not is just an implementation detail. Looking at this some more I think since we already use the $(shell) construct we could just have some 'configure-detect' Makefile target which would compile various test programs, and we'd use their output to set various settings, a sort of home-grown autoconf (because people are bound to have objections to a hard dependency on it...). > 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? Yes, but I think it's worth re-visiting that decision, which was made with the constraints that we don't have a build system that can do checks via compiled code, so we need this hack in the first place instead of things Just Working. And as I pointed out in the linked E-Mail this also impacts us in other ways, and will cause other issues in the future, so it's worth thinking about if this is the right path to take. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason 2018-07-30 14:54 ` Junio C Hamano @ 2018-07-31 10:39 ` Michael Felt 2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason 2018-07-31 12:32 ` Is detecting endianness at compile-time unworkable? Michael Felt 2018-07-31 14:01 ` Michael Felt 3 siblings, 1 reply; 25+ messages in thread From: Michael Felt @ 2018-07-31 10:39 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King A small step back... On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote: > On Sun, Jul 29 2018, Michael wrote: > >> On 29/07/2018 22:06, brian m. carlson wrote: >>> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote: >>>> On 29/07/2018 21:27, brian m. carlson wrote: >>>>> Well, that explains it. I would recommend submitting a patch to >>>>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can >>>>> pull in the updated submodule with that fix. >>>> Not sure I am smart enough to do that. I'll have to download, build, and see >>>> what it says. >>> The issue is that somewhere in lib/sha1.c, you need to cause >>> SHA1DC_BIGENDIAN to be set. That means you need to figure out what >>> compiler macro might indicate that. >> I remember - roughly - a few decades back - having an assignment to >> write code to determine endianness. PDP and VAC were different iirc, >> and many other micro-processors besides the 8088/8086/z85/68k/etc.. >> >> If you are looking for a compiler macro as a way to determine this - >> maybe you have one for gcc, but not for xlc. I do not know it - currently :) > I'm not familiar with AIX, but from searching around I found this > porting manual from IBM: > http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf This is from July 2001 - when AIX 5L, for Linux affinity, was new. AIX was (nearly) the #1 posix system, and linux was a minor player in the data center (in or out (now as IAAS)). IMHO, the recommendations made in 2001 are probably no longer applicable (64-bit was fairly new, e.g., rather than common). > > There they suggest either defining your own macros, or testing the > memory layout at runtime (see section "2.2.2.3 Technique 3: Testing > memory layout" and surrounding sections). > > Perhaps it's worth taking a step back here and thinking about whether > this whole thing is unworkable. It was hard enough to get this to work > on the combination of Linux, *BSD and Solaris, but I suspect we'll run > into increasingly obscure platforms where this is hard or impossible > (AIX, HP/UX etc.) > > The reason we're in this hole is because we use this > sha1collisiondetection library to do SHA-1, and the reason we have > issues with it specifically (not OpenSSL et al) is because its only > method of detecting endianness is at compile time. Cannot speak for the "others", but as I have mentioned before - as AIX in only on POWER it is also only Big Endian - so a compiletime #if testing for _AIX will work fine > This didn't use to be the case, it was changed in this commit: > https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672 > > Dan Shumow: Since the commit message doesn't say why, can you elaborate > a bit on why this was done, i.e. is determining this at runtime harmful > for performance? If not, perhaps it would be best to bring this back, at > least as an option. > > 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. On AIX - I am required to run configure, and frankly, I am amazed that not everyone is running it. Among other things I an modifying the prefix (to /opt) and many of the others to different /var/git/* areas as I do not want to "polute" the BOS (base OS) and/or other packages/packagers. Officially, according the Linux FHS-3.0 I sould be using /opt/aixtools as prefix. FYI: my current build process is: wget git-{version}.tar.xz xz -dc git-{version}.tar.xz cd git-{version}.tar.xz mv Makefile Makefile.git #my build scripts only run configure when Makefile does not exist ./configure ... ln Makefile.git Makefile make I am amazed, as it rarely happens (maybe git is my first encounter) - that configure does not create a Makefile. This also complicates building git "out of tree". > > Junio: I've barked up that particular tree before in > https://public-inbox.org/git/87a7x3kmh5.fsf@evledraar.gmail.com/ and I > won't bore you all by repeating myself, except to say that this is yet > another case where I wish we had a hard dependency on some way of doing > checks via compiled code in our build system. For AIX: again - the determination is simple. If _AIX is set to 1 then use BigEndian, or, use: michael@x071:[/home/michael]uname AIX i.e., something like: $(uname) == "AIX" && BigEndian=1 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-31 10:39 ` Michael Felt @ 2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason 2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-08-01 7:31 UTC (permalink / raw) To: Michael Felt; +Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King On Tue, Jul 31 2018, Michael Felt wrote: > For AIX: again - the determination is simple. If _AIX is set to 1 then > use BigEndian, or, use: > michael@x071:[/home/michael]uname > AIX > i.e., something like: > $(uname) == "AIX" && BigEndian=1 In lieu of some "let's test this with a compile-test" solution, that seems like a viable way forward for now. Can you please test the merge request I have at https://github.com/cr-marcstevens/sha1collisiondetection/pull/45 by manually applying that change to the relevant file in sha1dc/ and building/testing git on AIX? It should work, but as noted in the MR please test it so we can make sure, and then (if you have a GitHub account) comment on the MR saying it works for you. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH] sha1dc: update from upstream 2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason @ 2018-08-02 20:50 ` Ævar Arnfjörð Bjarmason 2018-08-02 21:29 ` Michael Felt (aixtools) 2018-08-02 21:32 ` Stefan Beller 0 siblings, 2 replies; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-08-02 20:50 UTC (permalink / raw) To: git Cc: Junio C Hamano, Michael Felt, brian m . carlson, Dan Shumow, Jeff King, Ævar Arnfjörð Bjarmason Update sha1dc from the latest version by the upstream maintainer[1]. See 2db87328ef ("Merge branch 'ab/sha1dc'", 2017-07-10) for the last update. This fixes an issue where AIX was wrongly detected as a Little-endian instead of a Big-endian system. See [2][3][4]. 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/232357eb2ea0397388254a4b188333a227bf5b10 2. https://github.com/cr-marcstevens/sha1collisiondetection/pull/45 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/42 4. https://public-inbox.org/git/20180729200623.GF945730@genre.crustytoothpaste.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- On Wed, Aug 01 2018, Ævar Arnfjörð Bjarmason wrote: > https://github.com/cr-marcstevens/sha1collisiondetection/pull/45 >[...] > It should work, but as noted in the MR please test it so we can make > sure, and then (if you have a GitHub account) comment on the MR saying > it works for you. This got merged upstream, and as noted in that upstream PR I've personally tested this on AIX under both GCC and IBM's xlc on the GCC compile farm, it works. sha1collisiondetection | 2 +- sha1dc/sha1.c | 12 +++++++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/sha1collisiondetection b/sha1collisiondetection index 19d97bf5af..232357eb2e 160000 --- a/sha1collisiondetection +++ b/sha1collisiondetection @@ -1 +1 @@ -Subproject commit 19d97bf5af05312267c2e874ee6bcf584d9e9681 +Subproject commit 232357eb2ea0397388254a4b188333a227bf5b10 diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c index 25eded1399..df0630bc6d 100644 --- a/sha1dc/sha1.c +++ b/sha1dc/sha1.c @@ -93,13 +93,23 @@ #define SHA1DC_BIGENDIAN /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */ +#elif (defined(_AIX)) + +/* + * Defines Big Endian on a whitelist of OSs that are known to be Big + * Endian-only. See + * https://public-inbox.org/git/93056823-2740-d072-1ebd-46b440b33d7e@felt.demon.nl/ + */ +#define SHA1DC_BIGENDIAN + +/* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> */ #elif defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR) /* * As a last resort before we do anything else we're not 100% sure * about below, we blacklist specific processors here. We could add * more, see e.g. https://wiki.debian.org/ArchitectureSpecificsMemo */ -#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <processor blacklist> */ +#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> or <processor blacklist> */ /* We do nothing more here for now */ /*#error "Uncomment this to see if you fall through all the detection"*/ -- 2.18.0.345.g5c9ce644c3 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] sha1dc: update from upstream 2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason @ 2018-08-02 21:29 ` Michael Felt (aixtools) 2018-08-02 21:32 ` Stefan Beller 1 sibling, 0 replies; 25+ messages in thread From: Michael Felt (aixtools) @ 2018-08-02 21:29 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: git, Junio C Hamano, brian m . carlson, Dan Shumow, Jeff King Sent from my iPhone > On 2 Aug 2018, at 22:50, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > Update sha1dc from the latest version by the upstream > maintainer[1]. See 2db87328ef ("Merge branch 'ab/sha1dc'", 2017-07-10) > for the last update. > > This fixes an issue where AIX was wrongly detected as a Little-endian > instead of a Big-endian system. See [2][3][4]. > > 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/232357eb2ea0397388254a4b188333a227bf5b10 > 2. https://github.com/cr-marcstevens/sha1collisiondetection/pull/45 > 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/42 > 4. https://public-inbox.org/git/20180729200623.GF945730@genre.crustytoothpaste.net/ > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> > --- > >> On Wed, Aug 01 2018, Ævar Arnfjörð Bjarmason wrote: >> https://github.com/cr-marcstevens/sha1collisiondetection/pull/45 >> [...] >> It should work, but as noted in the MR please test it so we can make >> sure, and then (if you have a GitHub account) comment on the MR saying >> it works for you. > > This got merged upstream, and as noted in that upstream PR I've > personally tested this on AIX under both GCC and IBM's xlc on the GCC > compile farm, it works. > Thanks. I already have git 2.18 in use with the manual patch. > sha1collisiondetection | 2 +- > sha1dc/sha1.c | 12 +++++++++++- > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/sha1collisiondetection b/sha1collisiondetection > index 19d97bf5af..232357eb2e 160000 > --- a/sha1collisiondetection > +++ b/sha1collisiondetection > @@ -1 +1 @@ > -Subproject commit 19d97bf5af05312267c2e874ee6bcf584d9e9681 > +Subproject commit 232357eb2ea0397388254a4b188333a227bf5b10 > diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c > index 25eded1399..df0630bc6d 100644 > --- a/sha1dc/sha1.c > +++ b/sha1dc/sha1.c > @@ -93,13 +93,23 @@ > #define SHA1DC_BIGENDIAN > > /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */ > +#elif (defined(_AIX)) > + > +/* > + * Defines Big Endian on a whitelist of OSs that are known to be Big > + * Endian-only. See > + * https://public-inbox.org/git/93056823-2740-d072-1ebd-46b440b33d7e@felt.demon.nl/ > + */ > +#define SHA1DC_BIGENDIAN > + > +/* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> */ > #elif defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR) > /* > * As a last resort before we do anything else we're not 100% sure > * about below, we blacklist specific processors here. We could add > * more, see e.g. https://wiki.debian.org/ArchitectureSpecificsMemo > */ > -#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <processor blacklist> */ > +#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> or <processor blacklist> */ > > /* We do nothing more here for now */ > /*#error "Uncomment this to see if you fall through all the detection"*/ > -- > 2.18.0.345.g5c9ce644c3 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] sha1dc: update from upstream 2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason 2018-08-02 21:29 ` Michael Felt (aixtools) @ 2018-08-02 21:32 ` Stefan Beller 1 sibling, 0 replies; 25+ messages in thread From: Stefan Beller @ 2018-08-02 21:32 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: git, Junio C Hamano, aixtools, brian m. carlson, Daniel Shumow, Jeff King On Thu, Aug 2, 2018 at 1:51 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > diff --git a/sha1collisiondetection b/sha1collisiondetection > index 19d97bf5af..232357eb2e 160000 > --- a/sha1collisiondetection > +++ b/sha1collisiondetection > @@ -1 +1 @@ > -Subproject commit 19d97bf5af05312267c2e874ee6bcf584d9e9681 > +Subproject commit 232357eb2ea0397388254a4b188333a227bf5b10 Offtopic: I wonder if we want to extend diffs a little here and similar to a diffstat that is not technically needed, but rather aiding the reviewers eyes. So maybe we could add a concise shortlog, e.g. after this line: 19d97bf5..232357eb (2 dots indicating it is a fast forward instead of 3 dots) 3 commits from "Merge pull request #37 from avar/fixup-pull-request-34" to "Merge pull request #45 from avar/aix-big-endian-detection" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason 2018-07-30 14:54 ` Junio C Hamano 2018-07-31 10:39 ` Michael Felt @ 2018-07-31 12:32 ` Michael Felt 2018-07-31 14:01 ` Michael Felt 3 siblings, 0 replies; 25+ messages in thread From: Michael Felt @ 2018-07-31 12:32 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King [-- Attachment #1: Type: text/plain, Size: 1744 bytes --] On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote: > The reason we're in this hole is because we use this > sha1collisiondetection library to do SHA-1, and the reason we have > issues with it specifically (not OpenSSL et al) is because its only > method of detecting endianness is at compile time. When using gcc (no xlc available for Linux on Power) POWER6 (Big Endian by definition) root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep -i end #define __ORDER_LITTLE_ENDIAN__ 1234 #define __BIG_ENDIAN__ 1 #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define _BIG_ENDIAN 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ SLES12 on POWER8 suse12test:~ # gcc -dM -E - < /dev/null | grep -i end #define __ORDER_LITTLE_ENDIAN__ 1234 #define _LITTLE_ENDIAN 1 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ *So, for compile time tests, when gcc is the compiler it seems the following defines are available** **__BIG_ENDIAN__, _BIG_ENDIAN, __LITTLE__ENDIAN__, _LITTLE_ENDIAN** **or something based on the value of __BYTE_ORDER__* I'll see if I can find something similar for xlc, but will only be able to test xlc on AIX. > > This didn't use to be the case, it was changed in this commit: > https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672 > > Dan Shumow: Since the commit message doesn't say why, can you elaborate > a bit on why this was done, i.e. is determining this at runtime harmful > for performance? If not, perhaps it would be best to bring this back, at > least as an option. [-- Attachment #2: Type: text/html, Size: 2629 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason ` (2 preceding siblings ...) 2018-07-31 12:32 ` Is detecting endianness at compile-time unworkable? Michael Felt @ 2018-07-31 14:01 ` Michael Felt 2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason 3 siblings, 1 reply; 25+ messages in thread From: Michael Felt @ 2018-07-31 14:01 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King I hope a I have a "leap forward" On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote: > Perhaps it's worth taking a step back here and thinking about whether > this whole thing is unworkable. It was hard enough to get this to work > on the combination of Linux, *BSD and Solaris, but I suspect we'll run > into increasingly obscure platforms where this is hard or impossible > (AIX, HP/UX etc.) While I still cannot say for HP/UX it does seem there is a potential solution based on the status for _LITTLE_ENDIAN and _BIG_ENDIAN. At least, gcc on POWER and xlc on POWER provides one or the other - and my hope is that gcc on other platforms also provides them. For "other" compilers that do not provide them - a modification to CFLAGS to define one or the other should make "make" work. Details (note - I am not a programmer, so by definition at least one of my "macros" will be wrong :) AIX and xlc root@x066:[/]xlc -qshowmacros -E /dev/null | grep -i endi 1506-297 (S) Unable to open input file null. A file or directory in the path name does not exist.. #define __HHW_BIG_ENDIAN__ 1 #define __BIG_ENDIAN__ 1 #define __THW_BIG_ENDIAN__ 1 #define _BIG_ENDIAN 1 On SLES12 (le) and xlc suse12test:~/images/littleEndian/sles # xlc -qshowmacros -dM -E x.c | grep -i endi #define _LITTLE_ENDIAN 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 #define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__ Based on what I can see on gcc on POWER and xlc on POWER I think an approach (simplified) can be: #if undefined(_BIG_ENDIAN) && undef(_LITTLE_ENDIAN) #error "one of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined. Try adding the correct value to CFLAGS" #else defined(_BIG_ENDIAN) && defined(_LITTLE_ENDIAN) #error "Only one of _BIG_ENDIAN and _LITTLE_ENDIAN may be defined, not both" #endif And then logic based on the value set. This should also make cross-compile possible by unsetting an incorrect default and setting the correct value. p.s. Is there a setting I need to set somewhere so I receive a copy of the email sent after it is received by the list. I could send myself a copy, but I much prefer it comes from the maillist - as verification it was received. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-31 14:01 ` Michael Felt @ 2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason 2018-07-31 20:06 ` Michael 0 siblings, 1 reply; 25+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2018-07-31 14:25 UTC (permalink / raw) To: Michael Felt; +Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King On Tue, Jul 31 2018, Michael Felt wrote: > I hope a I have a "leap forward" > > > On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote: >> Perhaps it's worth taking a step back here and thinking about whether >> this whole thing is unworkable. It was hard enough to get this to work >> on the combination of Linux, *BSD and Solaris, but I suspect we'll run >> into increasingly obscure platforms where this is hard or impossible >> (AIX, HP/UX etc.) > While I still cannot say for HP/UX it does seem there is a potential > solution based on the status for _LITTLE_ENDIAN and _BIG_ENDIAN. At > least, gcc on POWER and xlc on POWER provides one or the other - and my > hope is that gcc on other platforms also provides them. Yeah with GCC this is relatively easy, see https://github.com/cr-marcstevens/sha1collisiondetection/blame/c3e1304/lib/sha1.c#L29-L115 > For "other" compilers that do not provide them - a modification to > CFLAGS to define one or the other should make "make" work. > > Details (note - I am not a programmer, so by definition at least one of > my "macros" will be wrong :) > > AIX and xlc > root@x066:[/]xlc -qshowmacros -E /dev/null | grep -i endi > 1506-297 (S) Unable to open input file null. A file or directory in the > path name does not exist.. > #define __HHW_BIG_ENDIAN__ 1 > #define __BIG_ENDIAN__ 1 > #define __THW_BIG_ENDIAN__ 1 > #define _BIG_ENDIAN 1 > > On SLES12 (le) and xlc > suse12test:~/images/littleEndian/sles # xlc -qshowmacros -dM -E x.c | > grep -i endi > #define _LITTLE_ENDIAN 1 > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ > #define __LITTLE_ENDIAN__ 1 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__ > > > Based on what I can see on gcc on POWER and xlc on POWER I think an > approach (simplified) can be: > > #if undefined(_BIG_ENDIAN) && undef(_LITTLE_ENDIAN) > #error "one of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined. Try adding > the correct value to CFLAGS" > #else defined(_BIG_ENDIAN) && defined(_LITTLE_ENDIAN) > #error "Only one of _BIG_ENDIAN and _LITTLE_ENDIAN may be defined, not both" > #endif > > And then logic based on the value set. > This should also make cross-compile possible by unsetting an incorrect > default and setting the correct value. ...the real trick is using these macros outside of GCC / glibc and on older GCC versions. See the github link above, you basically end up with a whitelist of how it looks on different systems / compilers. Sometimes both are defined, sometimes only both etc. It can be done, but as that code shows it's somewhat complex macro soup to get right. > p.s. Is there a setting I need to set somewhere so I receive a copy of > the email sent after it is received by the list. I could send myself a > copy, but I much prefer it comes from the maillist - as verification it > was received. You should get that, but maybe your mailer ignores Message-Ids it already has, but you can go to https://public-inbox.org/git/ and search for the Message-Id or your name to see E-Mails you've sent that made it to the list, e.g.: https://public-inbox.org/git/?q=aixtools%40felt.demon.nl ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Is detecting endianness at compile-time unworkable? 2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason @ 2018-07-31 20:06 ` Michael 0 siblings, 0 replies; 25+ messages in thread From: Michael @ 2018-07-31 20:06 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King On 31/07/2018 16:25, Ævar Arnfjörð Bjarmason wrote: > ...the real trick is using these macros outside of GCC / glibc and on > older GCC versions. See the github link above, you basically end up with > a whitelist of how it looks on different systems / compilers. Sometimes > both are defined, sometimes only both etc. > > It can be done, but as that code shows it's somewhat complex macro soup > to get right. FYI - the gcc I was using is 4.7.4. And, the reason I suggest the test for both not being defined is so that 'make' stops and whoever is running make just sets one or the other. Let them 'file a bug' When they come with a compiler that does not work - and find out what could be used. For example, _AIX is the same as _BIG_ENDIAN. In the meantime, the code to test is simple. Either one of _BIG_ENDIAN or _LITTLE_ENDIAN is provided by the compiler or the builder supplies one of the two using CFLAGS. I assume there is also a "undefine" flag, maybe -U - so hopefully a -U and a -D combination could be used for cross-compiling. re: my mailer blocking things - it would only be for this list, as other lists come through with no extra work from me. At least I am not aware of anything special I could do. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-08-02 21:32 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-29 16:44 git broken for AIX somewhere between 2.13.2 and 2.13.3 Michael 2018-07-29 18:10 ` brian m. carlson 2018-07-29 19:46 ` Michael 2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason 2018-07-29 21:40 ` Andreas Schwab 2018-07-30 6:22 ` Michael [not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl> [not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net> 2018-07-29 19:48 ` Michael 2018-07-29 20:06 ` brian m. carlson 2018-07-29 20:50 ` Michael 2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason 2018-07-30 14:54 ` Junio C Hamano 2018-07-30 18:32 ` Junio C Hamano 2018-07-30 18:39 ` Daniel Shumow 2018-07-31 10:06 ` Michael Felt 2018-08-01 1:35 ` Eric Wong 2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason 2018-07-31 10:39 ` Michael Felt 2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason 2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason 2018-08-02 21:29 ` Michael Felt (aixtools) 2018-08-02 21:32 ` Stefan Beller 2018-07-31 12:32 ` Is detecting endianness at compile-time unworkable? Michael Felt 2018-07-31 14:01 ` Michael Felt 2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason 2018-07-31 20:06 ` Michael
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).