Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jan 2016 07:54:43 +0000
From:      bugzilla-noreply@freebsd.org
To:        ruby@FreeBSD.org
Subject:   maintainer-feedback requested: [Bug 206664] lang/ruby21: miniruby gets bus error on arm that requires alignment (SCTLR bit[1]==1); build fails
Message-ID:  <bug-206664-21402-Uam5y8i0iQ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-206664-21402@https.bugs.freebsd.org/bugzilla/>
References:  <bug-206664-21402@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
Mark Millard <markmi@dsl-only.net> has reassigned Bugzilla Automation
<bugzilla@FreeBSD.org>'s request for maintainer-feedback to ruby@FreeBSD.or=
g:
Bug 206664: lang/ruby21: miniruby gets bus error on arm that requires align=
ment
(SCTLR bit[1]=3D=3D1); build fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206664



--- Description ---
To show the Bus Error details I show running the miniruby that the build had
produced directly under gdb:

# gdb /usr/obj/portswork/usr/ports/lang/ruby21/work/ruby-2.1.8/miniruby
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "armv6-marcel-freebsd"...
(gdb) run
Starting program:
/usr/obj/portswork/usr/ports/lang/ruby21/work/ruby-2.1.8/miniruby=20
[New LWP 100182]
[New Thread 20810000 (LWP 100182/miniruby)]


Program received signal SIGBUS, Bus error.
[Switching to Thread 20810000 (LWP 100182/miniruby)]
0x00223ae4 in $a.107 () at compile.c:1610
1610				    *ci =3D *base_ci;
(gdb) info threads
[New Thread 20810300 (LWP 100247/miniruby)]
  3 Thread 20810300 (LWP 100247/miniruby)  0x204e891c in _poll () from
/lib/libc.so.7
* 2 Thread 20810000 (LWP 100182/miniruby)  0x00223ae4 in $a.107 () at
compile.c:1610
(gdb) bt
#0  0x00223ae4 in $a.107 () at compile.c:1610
#1  0x00223680 in $a.105 () at compile.c:1529
(gdb) x/30i 0x00223ad0
0x223ad0 <$a.107+748>:	add	r0, r1, r0, lsl #6
0x223ad4 <$a.107+752>:	str	r0, [sp, #72]
0x223ad8 <$a.107+756>:	ldr	r1, [sp, #76]
0x223adc <$a.107+760>:	add	r2, r0, #48	; 0x30
0x223ae0 <$a.107+764>:	add	r3, r1, #48	; 0x30
0x223ae4 <$a.107+768>:	vld1.64 {d16-d17}, [r3]
0x223ae8 <$a.107+772>:	vst1.64 {d16-d17}, [r2]
0x223aec <$a.107+776>:	add	r2, r0, #32	; 0x20
0x223af0 <$a.107+780>:	add	r3, r1, #32	; 0x20
0x223af4 <$a.107+784>:	vld1.64 {d16-d17}, [r3]
0x223af8 <$a.107+788>:	vst1.64 {d16-d17}, [r2]
0x223afc <$a.107+792>:	vld1.64 {d16-d17}, [r1]!
0x223b00 <$a.107+796>:	vst1.64 {d16-d17}, [r0]!
0x223b04 <$a.107+800>:	vld1.64 {d16-d17}, [r1]
0x223b08 <$a.107+804>:	vst1.64 {d16-d17}, [r0]
0x223b0c <$a.107+808>:	ldr	r0, [sp, #76]
0x223b10 <$a.107+812>:	ldr	r0, [r0, #56]
0x223b14 <$a.107+816>:	ldr	r1, [r11, #-8]
0x223b18 <$a.107+820>:	ldr	r1, [r1, #76]
0x223b1c <$a.107+824>:	cmp	r0, r1
0x223b20 <$a.107+828>:	blt	0x223b48 <$a.107+868>
0x223b24 <$a.107+832>:	b	0x223b28 <$a.107+836>
0x223b28 <$a.107+836>:	ldr	r0, [sp, #76]
0x223b2c <$a.107+840>:	ldr	r1, [r0, #44]
0x223b30 <$a.107+844>:	ldr	r0, [r11, #-8]
0x223b34 <$a.107+848>:	ldr	r2, [r0, #76]
0x223b38 <$a.107+852>:	ldr	r0, [pc, #1000] ; 0x223f28 <$d.108+4>
0x223b3c <$a.107+856>:	add	r0, pc, r0
0x223b40 <$a.107+860>:	mov	lr, pc
0x223b44 <$a.107+864>:	b	0x79f48 <rb_bug>
(gdb) info registers
r0	       0x20829280	545428096
r1	       0x2094e62c	546629164
r2	       0x208292b0	545428144
r3	       0x2094e65c	546629212
r4	       0x1	1
r5	       0x0	0
r6	       0xbfbfe32c	-1077943508
r7	       0xbfbf9718	-1077962984
r8	       0x20922600	546448896
r9	       0x20922828	546449448
r10	       0x20922720	546449184
r11	       0xbfbf95c0	-1077963328
r12	       0x29	41
sp	       0xbfbf94f8	-1077963528
lr	       0x223680 2242176
pc	       0x223ae4 2243300
fps	       0x0	0
cpsr	       0x80000010	-2147483632

The "vld1.64	{d16-d17}, [r3]" require 8 byte alignment for an armv7-a with
SCTLR bit[1]=3D=3D1 but r3=3D0x2094e65c does not meet that criteria.

The original failure notices were:

linking miniruby
--- .rbconfig.time ---
--- encdb.h ---
generating encdb.h
./miniruby: [BUG] Bus Error at 0x2094e65c
ruby 2.1.8p440 (2015-12-16 revision 53160) [armv6-freebsd11]

-- Control frame information -----------------------------------------------
c:0001 p:0000 s:0002 E:0015c4 TOP    [FINISH]


-- Other runtime information -----------------------------------------------

* Loaded script: ./miniruby

* Loaded features:

    0 enumerator.so

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension librari=
es.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

--- .rbconfig.time ---
./miniruby: [BUG] Bus Error at 0x2094e65c
ruby 2.1.8p440 (2015-12-16 revision 53160) [armv6-freebsd11]

-- Control frame information -----------------------------------------------
c:0001 p:0000 s:0002 E:0015c4 TOP    [FINISH]


-- Other runtime information -----------------------------------------------

* Loaded script: ./miniruby

* Loaded features:

    0 enumerator.so

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension librari=
es.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html


But the .core files produced do not show the original Bus Error(s) so I sho=
wed
the run above instead.


Of note is that I'm working on a RPI2B and everything from
buildworld/buildkernel to ports in my build activities are targeting the
armv7-a/cortex-a7 that an RPI2B has, not a more generic armv6. Also I'm usi=
ng
projects/clang380-import because clang++ 3.7.1 Bus Errors during most C++
compiles. 3.8.0 has a bunch of alignment fixes in it to allow use with SCTLR
Bit[1]=3D=3D1 (and on sparc's that require alignment).

As for the details of targeting armv7-a and cortex-a7, I show some of the
checking output that shows the command's arguments for such:

checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/clang -target armv6--freebsd11.0-gnueabi
-march=3Darmv7-a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-acce=
ss accepts
-g... yes
checking for /usr/bin/clang -target armv6--freebsd11.0-gnueabi -march=3Darm=
v7-a
-mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-access option to acce=
pt ISO
C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi
-march=3Darmv7-a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-acce=
ss accepts
-g... yes
checking how to run the C preprocessor... /usr/bin/clang-cpp -target
armv6--freebsd11.0-gnueabi -march=3Darmv7-a -mcpu=3Dcortex-a7 -mfloat-abi=
=3Dsoftfp
-mno-unaligned-access

My /usr/ports is at -r407323 on the RPI2B as I'm doing this activity.

Note: I was not directly trying to use ruby. I was just trying to do a ports
based install of portupgrade (that in turn depends on ruby).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206664-21402-Uam5y8i0iQ>