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
Nicholas Clark
May 22, 2013 11:33
Re: [perl #118055] miniperl fails with SIGBUS on sparc(usethreads+use64bitint)
Message ID:
On Tue, May 21, 2013 at 05:02:38PM -0400, Andy Dougherty wrote:
> On Tue, 21 May 2013, Nicholas Clark wrote:

> > 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.

Interesting. So newer gcc is generating instructions that require alignment,
and older gcc is not. And "old Sparc Solaris" meant that newer Sparc Solaris
didn't (ie newer hardware can do misaligned reads?)

> > 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 don't think that this is correct, as I've read that mips can enable SIGBUS
on misaligned reads, hence at least one other architecture potentially needs

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

I hope to have something sooner than that.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About