U32 alignment on 64-bit arch [rt.cpan.org #77919]

[toddr]

Migrated from rt.cpan.org#77919 (status was 'open')

Requestors:

• zefram@fysh.org

Attachments:

diff -ur Digest-MD5-2.52.orig/Makefile.PL Digest-MD5-2.52.mod0/Makefile.PL
--- Digest-MD5-2.52.orig/Makefile.PL	2012-06-07 23:16:21.000000000 +0100
+++ Digest-MD5-2.52.mod0/Makefile.PL	2012-06-20 12:10:18.693705783 +0100
@@ -79,7 +79,7 @@
 
 int main(int argc, char** argv, char** env)
 {
-#if BYTEORDER == 0x1234 || BYTEORDER == 0x4321
+#if BYTEORDER == 0x1234 || BYTEORDER == 0x4321 || BYTEORDER == 0x12345678 || BYTEORDER == 0x87654321
     volatile U8 buf[] = "\0\0\0\1\0\0\0\0";
     volatile U32 *up;
     int i;

From zefram@fysh.org on 2012-06-20 11:20:22
:

Digest-MD5's U32 alignment test perceives any 64-bit architecture as
an "unusual byte order", and unnecessarily plays safe, losing some
performance.  Attached patch fixes.

-zefram

From zefram@fysh.org on 2012-06-20 11:50:21
:

Second thoughts: some of the code in MD5.xs needs to be edited as well
to cope with a 64-bit BYTEORDER.  I'm somewhat amazed that this didn't
show up immediately in the test suite.

-zefram

From rurban@cpan.org on 2016-03-27 08:52:36
:

On Wed Jun 20 07:50:21 2012, zefram@fysh.org wrote:
> Second thoughts: some of the code in MD5.xs needs to be edited as well
> to cope with a 64-bit BYTEORDER.  I'm somewhat amazed that this didn't
> show up immediately in the test suite.

perl5 core took over the same wrong d_u32align probe which fails on all intel cpus,
unless the AC bit (alignment check) in EFLAGS is set. See http://orchistro.tistory.com/206
how to enforce a SIGBUS on intel also, e.g. when U32_ALIGNMENT_REQUIRED is wrongly set.
I do this to check on fast intel for possible SIGBUS errors for alignment strict platforms (mips,sparc,ppc).

See https://github.com/gisle/digest-md5/pull/13

It needs to link with -lperl
-- 
Reini Urban

[toddr]

@rurban submitted gisle#13 but it appears to be failing CI at this time. I would love a proper fix here when it is available.

[toddr]

@mattst88, can I conclude that this case has been resolved by 2503291

[rurban]

no, certainly not. you removed the big endian code, and the alignment code.

[toddr]

no, certainly not. you removed the big endian code, and the alignment code.

Correct, this was done via Perl/perl5@ee9ac1c. You can see this issue for more information. Perl/perl5#16680

[toddr]

The only relevant part of gisle#13 I can see that might be relevant still is this :/

diff --git a/MD5.xs b/MD5.xs
index 581b0e6..6e0a647 100644
--- a/MD5.xs
+++ b/MD5.xs
@@ -788,3 +788,21 @@ md5(...)
        MD5Final(digeststr, &ctx);
         ST(0) = make_mortal_sv(aTHX_ digeststr, ix);
         XSRETURN(1);
+
+BOOT:
+#if defined(U32_ALIGNMENT_REQUIRED) && defined(__GNUC__) && (defined(__x86_64__) || defined(__i386))
+        /* Generate SIGBUS on unaligned access even on x86:
+           Set AC in EFLAGS. See http://orchistro.tistory.com/206
+           Also see https://sourceforge.net/p/predef/wiki/Architectures/
+           for possible other compilers. Here only GNU C: gcc, clang, icc.
+           MSVC would be nice also. */
+#ifdef __x86_64__
+        __asm__("pushf\n"
+                "orl $0x40000, (%rsp)\n"
+                "popf");
+#else
+        __asm__("pushf\n"
+                "orl $0x40000, (%esp)\n"
+                "popf");
+#endif
+#endif