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:
Andy Dougherty
Date:
May 21, 2013 21:03
Subject:
Re: [perl #118055] miniperl fails with SIGBUS on sparc(usethreads+use64bitint)
Message ID:
alpine.DEB.2.02.1305211650450.7468@fractal.phys.lafayette.edu
On Tue, 21 May 2013, Nicholas Clark 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:

I was able to replicate it on an old Sparc Solaris system.  It compiles 
successfully with gcc-3.4.3, but fails with gcc-4.1.0 and gcc-4.6.0.

> 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

Yes, I suspect so.
> 
> 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).

It could perhaps be protected by #ifdef __sparc__/#endif conditionals.

I may be able to look at this late next week.

-- 
    Andy Dougherty		doughera@lafayette.edu

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