develooper Front page | perl.perl5.porters | Postings from May 2013

Re: [perl #118055] miniperl fails with SIGBUS on sparc (usethreads+use64bitint)

Thread Previous | Thread Next
From:
=?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
Date:
May 21, 2013 18:30
Subject:
Re: [perl #118055] miniperl fails with SIGBUS on sparc (usethreads+use64bitint)
Message ID:
CA+OH3v3CMnggmeEEoDNVG-V+=urn9TVe6Bct8JGKP=FwD7HA4A@mail.gmail.com
All RISC architectures prefer the natural alignment of data types,
i.e. 64bit must be 64bit aligned, 32bit must be 32bit aligned, and so
on.
 However, there are extra load and store instructions which are
slower, but do not trigger SIGBUS. gcc on some platforms and
architectures prefers the slow instructions (or byte-by-byte
loads/stores) for better compatibility, but on others it uses the
fast, but more tricky load/store instructions which require natural
alignment.

On Solaris/SPARC the Sun Studio compiler always uses the fast
instructions which always require the natural alignment. gcc on SPARC,
depending on version, uses the fast instructions when it thinks its
safe to use them and falls back to the slow byte-per-byte loads
otherwise.
MIPS has the same requirements, but the gcc compiler creates crap
which is always safe, at the costs of performance.

Olga

On Tue, May 21, 2013 at 8:14 PM, Nicholas Clark <nick@ccl4.org> wrote:
> On Mon, May 20, 2013 at 08:19:42AM +0100, Nicholas Clark wrote:
>> On Mon, May 20, 2013 at 05:11:38AM +0200, Leon Timmermans wrote:
>> > On Sun, May 19, 2013 at 9:50 PM, Niko Tyni <perlbug-followup@perl.org> wrote:
>
>> > > Bisecting says the first bad commit is
>> > >
>> > > commit 8be227ab5eaa23f2d21fd15f70190e494496dcbe
>> > > Author: Father Chrysostomos <sprout@cpan.org>
>> > > Date:   Sat Jun 23 09:54:31 2012 -0700
>> > >
>> > >     CV-based slab allocation for ops
>> >
>> > That makes perfect sense with my theory. Probably that allocator
>> > should do some padding to 64-bit boundaries.
>>
>> I think it needs to be to the alignment of the largest thing in an OP.
>> Which on a 32 bit sparc with 64 bit IVs is (currently) 64 bits:
>>
>>
>> struct pmop {
>>     BASEOP
>>     OP *      op_first;
>>     OP *      op_last;
>> #ifdef USE_ITHREADS
>>     IV          op_pmoffset;
>> #else
>>     REGEXP *    op_pmregexp;            /* compiled expression */
>> #endif
>
> I can replicate this on one of the sparc linux machines on the GCC compile
> farm. For -Duse64bitint:
>
> sizeof(struct op) = 20          __alignof__(struct op) = 4
> sizeof(struct unop) = 24        __alignof__(struct unop) = 4
> sizeof(struct binop) = 28       __alignof__(struct binop) = 4
> sizeof(struct logop) = 28       __alignof__(struct logop) = 4
> sizeof(struct listop) = 28      __alignof__(struct listop) = 4
> sizeof(struct pmop) = 56        __alignof__(struct pmop) = 8
> sizeof(struct svop) = 24        __alignof__(struct svop) = 4
> sizeof(struct padop) = 24       __alignof__(struct padop) = 4
> sizeof(struct pvop) = 24        __alignof__(struct pvop) = 4
> sizeof(struct loop) = 40        __alignof__(struct loop) = 4
> sizeof(struct cop) = 48         __alignof__(struct cop) = 4
>
>
> I get identical output from a mips machine, but it doesn't BUS ERROR.
> So I infer that mips is not as strict on alignment of 64 bit integers.
> I don't know if there are architectures other than sparc which are strict
> about alignment.
>
>
> I'm thinking about the least worst way to fix this. I notice that
>
> 1) almost nothing on CPAN uses the macros NewOp() and NewOpSz()
> 2) nothing on CPAN cheats and calls Perl_Slab_Alloc() directly
>
> So I infer that no code out there calls the slab allocator for arbitrary
> sized things, and that the only thing requested which needs 8 byte alignment
> (on some platforms) will have a size of 56.
>
> So I'm wondering if that's the way to go for maint-5.18
>
> Whilst it's cleaner, I'm wary of the idea of aligning everything to 8
> (for all platforms where sizeof(IV) > sizeof(void *)) because it will
> penalise ARM and x86 for BASOPs, BINOPs and LOGOPs, which are fairly
> common (I believe).
>
> Nicholas Clark



-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----'-/`-/     olga.kryzhanovska@gmail.com   \-`\-'----.
 `'-..-| /       http://twitter.com/fleyta     \ |-..-'`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About