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 conditions. 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 [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 = *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]==1 but r3=0x2094e65c 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 libraries. 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 libraries. 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 showed 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 using 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]==1 (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=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access accepts -g... yes checking for /usr/bin/clang -target armv6--freebsd11.0-gnueabi -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access option to accept 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=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access accepts -g... yes checking how to run the C preprocessor... /usr/bin/clang-cpp -target armv6--freebsd11.0-gnueabi -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -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).
I attempted a powerpc64 (big endian) build of portupgrade (and so of ruby21). miniruby again had pointer problems, in this case a segmentation violation that stopped the build. Again using a separate explicit run under gdb to show detail: # /usr/local/bin/gdb /usr/obj/portswork/usr/ports/lang/ruby21/work/ruby-2.1.8/miniruby GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] . . . (gdb) run Starting program: /usr/obj/portswork/usr/ports/lang/ruby21/work/ruby-2.1.8/miniruby [New Thread 50a15000 (LWP 100208)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 50a15000 (LWP 100208)] 0x00000000100a964c in gc_mark_roots (objspace=0xffffffffffffc608, full_mark=0, categoryp=0xffffffffffffc608) at gc.c:4122 4122 rb_gc_mark_maybe(*list->varptr); (gdb) x/4i 0x00000000100a9644 0x100a9644 <gc_mark_roots+492>: ld r3,120(r31) 0x100a9648 <gc_mark_roots+496>: ld r3,0(r3) => 0x100a964c <gc_mark_roots+500>: ld r3,0(r3) 0x100a9650 <gc_mark_roots+504>: bl 0x100a4b08 <rb_gc_mark_maybe> (gdb) info registers . . . r3 0x6c696265786563 30515168814851427 . . . r31 0xffffffffffffc560 18446744073709536608 . . .
(In reply to Mark Millard from comment #1) I should have noted that the compiler involved was clang 3.7.1 for mkaing teh failing miniruby. A later devel/powerpc64-gcc based build (with its new gcc 5.3.0 update already in place as it turns out) did not produce a miniruby that failed.
Relative to the powerpc64 segmentation faults I'll note that the powerpc64 clang does report the following sorts of warnings that means the code involved is dependent on undefined behavior that various compilers could treat differently: vm_dump.c:48:13: warning: shifting a negative signed value is undefined [-Wshift-negative-value] switch (VM_FRAME_TYPE(cfp)) { ^~~~~~~~~~~~~~~~~~ ./vm_core.h:772:43: note: expanded from macro 'VM_FRAME_TYPE' #define VM_FRAME_TYPE(cfp) ((cfp)->flag & VM_FRAME_MAGIC_MASK) ^~~~~~~~~~~~~~~~~~~ ./vm_core.h:770:36: note: expanded from macro 'VM_FRAME_MAGIC_MASK' #define VM_FRAME_MAGIC_MASK (~(~0<<VM_FRAME_MAGIC_MASK_BITS)) ~~^ . . . parse.y:1360:4: warning: shifting a negative signed value is undefined [-Wshift-negative-value] nd_set_line((yyval.node), (yyvsp[(2) - (5)].num)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./node.h:290:43: note: expanded from macro 'nd_set_line' RNODE(n)->flags=((RNODE(n)->flags&~(-1<<NODE_LSHIFT))|(((l)&NODE_LMASK)<<NODE_LSHIFT)) ~~^ (Many messages, just a couple extracted for here.) There were a few examples of messages like: re.c:106:11: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] if (y = memmem(ys, n, xs, m)) ~~^~~~~~~~~~~~~~~~~~~~~~ but this does not get into undefined behavior.
(In reply to Mark Millard from comment #0 and #3) I have verified that for the RPI2B context using gcc5 as the compiler allows miniruby to run. So, again, a clang vs. gcc distinction. Using a RPI2 clang 3.8.0 (from a projects/clang380-import context) produces the same warnings as via the powerpc64 clang 3.7.1, including the ones about undefined behavior. So gcc vs. clang may handle shifting negative values differently in some contexts (since there is no language definition of the result).
https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013925.html has reported that the FreeBSD requirement for strict alignment may be going away for armv6/armv7. If so after testing it may be that this defect is to be marked as no longer applying.
(In reply to Mark Millard from comment #5) Under 11.0 -r301815 ruby-2.2.5,1 builds and installs from source just fine on an rpi2 [armv7-a/cortex-a7]. The less strict alignment requirements in the more modern 11.0 have made the miniruby used during the build compatible.