This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
re-work opslab handling to avoid non-portable alignment assumptions
authorTony Cook <tony@develop-help.com>
Thu, 25 Jun 2020 05:26:32 +0000 (15:26 +1000)
committerKarl Williamson <khw@cpan.org>
Thu, 30 Jul 2020 22:08:59 +0000 (16:08 -0600)
commitf0cfed98a12d7c2954864f82237387d2b85de5c5
tree8f29bc5b548f86cf1c36c450d79e4ae46e3cc1bd
parent95c9b7e93b37d874a0f6f2a3c25fbe1121199124
re-work opslab handling to avoid non-portable alignment assumptions

Fixes #17871

The op slab allocator code made the assumption that since OP and
hence OPSLOT contain pointers, the base of each of those would be
an integral number of sizeof(pointer) (pointer units) from the
beginning of OPSLAB.

This assumption is non-portable, and broke calculating the location
of the slab based on the address of the op slot and the op slot offset
on m68k platforms.

To avoid that, this change now stores the opslot_offset as the
offset in pointer units from the beginning of opslab_slots rather
than from the beginning of the slab.

If alignment on a pointer boundary for OPs is required, the compiler
will align opslab_opslots and since we work in pointer units from there,
any allocated op slots will also be aligned.

If we assume PADOFFSET is no larger than a pointer and requires no
stricter alignment and structures in themselves have no stricter
alignment requirements then since we work in pointer units all core
OP structures should have sufficient alignment (if this isn't true,
then it's not a new problem, and not the problem I'm trying to solve
here.)

I haven't been able to test this on m68k hardware (the emulator I
tried to use can't maintain a network connection.)
op.c
op.h