develooper Front page | perl.perl5.porters | Postings from July 2019

[perl #133803] ExtUtils-MakeMaker in perl 5.28 armv5te fails

Tony Cook via RT
July 9, 2019 01:26
[perl #133803] ExtUtils-MakeMaker in perl 5.28 armv5te fails
Message ID:
On Sun, 30 Jun 2019 15:27:55 -0700, wrote:
> On Tue, 25 Jun 2019 15:27:08 -0700, wrote:
> > On Tue, 05 Feb 2019 20:18:43 -0800, tonyc wrote:
> > > Inside the perl build directory please run:
> > >
> > > ./miniperl -Mversion -e0
> > >
> > > Please include everything that outputs if it fails.
> >
> > I have this same issue when trying to build stock 5.28 (or .30) Perl
> > on armv5tel (Linux v5.1, GCC 8.3.0, glibc 2.29).
> >
> > perl-5.30.0$ ./miniperl -I./cpan/version/lib -I./lib -Mversion -e0
> > Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR
> > ref while "strict refs" in use at cpan/version/lib/ line
> > 21.
> > Compilation failed in require.
> > BEGIN failed--compilation aborted.
> This issue seems to be caused by wrong alignment causing unexpected
> behaviour. Running Configure with -Dd_u32align makes the build
> succeed.
> The Configure alignment test produces wrong result for ARMv5t with
> modern GCC:
> Checking to see whether you can access character data unalignedly...
> (Testing for character data alignment may crash the test.  That's
> okay.)
> You can access character data pretty unalignedly.
> The issue is seen on other platforms as well, e.g. SPARC (see #133495)
> and PA-RISC, where miniperl fails with SIGBUS.

There's a few problems between the test code in Configure, the assumptions made in hv_macro.h, and in the implementation in gcc.

Firstly the test code in Configure.

ARMv5 is pretty strange[1] when reading from unaligned addresses, instead of throwing an exception or reading the four bytes (for 32-bit reads) starting from the specified address, it reads from the address with the bottom two bits masked off, then uses those two bits as a rotate count (in multiples of 8).

On writes it simply ignores the bottom two bits.

This would mean that the read test code in the probe might get a false success.

The write code should however reject it, assuming the optimiser didn't intervene.

The other major problem is the optimiser acting as if the unaligned access behaved like x86 (ignoring endianess), and optimising out the test, not just on ARM.[2]

We could modify the test to detect the ARMv5 read strangeness, and maybe make the write test more robust, since if writes on ARMv5 behaved like the inverse of reads, we'd have brokenly accepted ARMv5 as allowing unaligned access, even without the intervention of the optimiser.

The other fix to be done here is working around the optimiser, which I suspect will be a race between ours and the compiler writer's ingenuity.

Secondly, the code in hv_macro.h

The probe in Configure only checks for 32-bit unaligned access, but the code in hv_macro.h assumes that this applies also to 64-bit accesses, which might not be the case.

This would need to be fixed by a separate 64-bit probe.

Thirdly, the code generated.

At least in 2010 the code generated for __builtin_bswap() on older ARM was fairly horrible[3], the fallback code might be preferable.  Detecting this at Configure or compilation time might be difficult though (maybe nm on a test .o to see if __bswapdi2() is being referenced.)



[2] Since access to unaligned addresses produces undefined behaviour, gcc is doing nothing wrong here.


via perlbug:  queue: perl5 status: open Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About