Date: Fri, 16 Nov 2018 20:45:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: ports-list freebsd <freebsd-ports@freebsd.org>, freebsd-ruby@freebsd.org Cc: Jan Beich <jbeich@FreeBSD.org> Subject: Re: ports head -r484652: lang/ruby24 fails to amd64 -> armv7 cross build: qemu: uncaught target signal 11 (2 of them) [armv7 native build worked] Message-ID: <BF4BDC55-AF3E-4423-B76D-2ACC9D433C46@yahoo.com> In-Reply-To: <D8F3BBAE-382B-4C39-9DA9-DCC349505C27@yahoo.com> References: <0E2549AE-5235-40C3-A5F8-4D66D3F3E0E5@yahoo.com> <D8F3BBAE-382B-4C39-9DA9-DCC349505C27@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Top post about bad comparison: The comparison to x11/pixman turns out to be a misnomer. More testing by Jan B. showed that -O2 vs -O was not sufficient to control the behavior for x11/pixman's builds. pixman's issue traces back to use of .object_arch armv4 in four .S files and them causing R_ARM_V4BX relocation record use, which lld only had support-for checked in to llvm's truck today (2018-Nov-16). Despite that, the build environment's use of -O2 instead of -O is real for poudriere/qemu-arm-static/nxb/. . . use. ruby's problem is not tied to R_ARM_V4BX use: different problem. (No updated text below. The above did not fit there well.) On 2018-Nov-15, at 11:46, Mark Millard <marklmi at yahoo.com> wrote: > [While the poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 > cross build failed, a native armv7 build worked. It turns out the > difference that matters is likely -O2 use vs -O use. More later > below.] >=20 > On 2018-Nov-10, at 23:29, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> Poudriere-devel reported: >>=20 >> [00:18:32] [07] [00:02:56] Saved lang/ruby24 | ruby-2.4.5,1 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/ruby-2= .4.5,1.tbz >> [00:18:32] [07] [00:02:56] Finished lang/ruby24 | ruby-2.4.5,1: = Failed: build >>=20 >> The log showed: >>=20 >> --- miniruby --- >> linking miniruby >> --- .rbconfig.time --- >> --- encdb.h --- >> generating encdb.h >> --- .rbconfig.time --- >> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >> Segmentation fault >> *** [.rbconfig.time] Error code 139 >>=20 >> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5 >> --- encdb.h --- >> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >> Segmentation fault >> *** [encdb.h] Error code 139 >>=20 >> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5 >> 2 errors >>=20 >>=20 >> Despite how the above looks, I find only one .core file in the >> tar archive produced for the failure: >>=20 >> # find /wrkdirs/usr/ports/lang/ruby/ -name "*.core" -print >> /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/qemu_miniruby.core >>=20 >> Apparently qemu does not allow for separate files for distinct >> processes. >>=20 >> For that .core file I find (libexec/gdb): >>=20 >> # chroot /usr/obj/DESTDIRs/clang-armv7-installworld-poud >> # cd /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/ >> # /usr/libexec/gdb miniruby qemu_miniruby.core=20 >> . . . >> (gdb) bt >> #0 0x00113f84 in rb_gc_writebarrier_unprotect (obj=3D4104601600) at = gc.c:1119 >> 1119 return RVALUE_WB_UNPROTECTED_BITMAP(obj) !=3D 0; >> [New Thread f4b5d000 (LWP 100638/<unknown>)] >> [New LWP 61684] >> Current language: auto; currently minimal >> (gdb) bt >> #0 0x00113f84 in rb_gc_writebarrier_unprotect (obj=3D4104601600) at = gc.c:1119 >> #1 0x000c3fc8 in rb_include_class_new (module=3D4104569400, = super=3D<value optimized out>) at ruby.h:1456 >> #2 0x000c4424 in include_modules_at (klass=3D4104602160, = c=3D4104602160, module=3D4104569400, search_super=3D<value optimized = out>) at class.c:913 >> #3 0x000c41f0 in rb_include_module (klass=3D4104602160, = module=3D4104569400) at class.c:870 >> #4 0x001f6dec in Init_String () at string.c:10021 >> #5 0x00129398 in rb_call_inits () at inits.c:28 >> #6 0x00103bac in ruby_setup () at eval.c:60 >> #7 0x00103be8 in ruby_init () at eval.c:76 >> #8 0x000a3300 in main (argc=3D11, argv=3D0x9fffe41c) at main.c:35 >> (gdb) up >> #1 0x000c3fc8 in rb_include_class_new (module=3D4104569400, = super=3D<value optimized out>) at ruby.h:1456 >> 1456 rb_gc_writebarrier_unprotect(x); >> (gdb) up >> #2 0x000c4424 in include_modules_at (klass=3D4104602160, = c=3D4104602160, module=3D4104569400, search_super=3D<value optimized = out>) at class.c:913 >> 913 iclass =3D rb_include_class_new(module, = RCLASS_SUPER(c)); >> (gdb) up >> #3 0x000c41f0 in rb_include_module (klass=3D4104602160, = module=3D4104569400) at class.c:870 >> 870 changed =3D include_modules_at(klass, RCLASS_ORIGIN(klass), = module, TRUE); >> (gdb) up >> #4 0x001f6dec in Init_String () at string.c:10021 >> 10021 rb_include_module(rb_cString, rb_mComparable); >> (gdb) up >> #5 0x00129398 in rb_call_inits () at inits.c:28 >> 28 CALL(String); >> (gdb) up >> #6 0x00103bac in ruby_setup () at eval.c:60 >> 60 rb_call_inits(); >> (gdb) up >> #7 0x00103be8 in ruby_init () at eval.c:76 >> 76 int state =3D ruby_setup(); >> (gdb) up >> #8 0x000a3300 in main (argc=3D11, argv=3D0x9fffe41c) at main.c:35 >> 35 ruby_init(); >>=20 >> (I'm not familiar with what details libexec/gdb gets >> right vs. wrong. But the call chain seems coherent.) >>=20 >> Host environment: >>=20 >> # uname -apKU >> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r340287M: Fri = Nov 9 08:37:01 PST 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG amd64 amd64 1300003 1300003 >=20 > A prior example that fails for native armv7 builds > but works for poudriere-devel/qemu-arm-static/nxb-bin/ > (native cross tools based) amd64 -> armv7 cross builds > is x11/pixman. >=20 > Previously I discovered that x11/pixman builds fine in > poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 > cross builds but a link fails during native armv7 > builds. It turned out that with the host-native cross > tools involved -O2 was being used where native -O > was being used: the code in share/mk/sys.mk that > is designed to use -O for arm fails to do so and uses > -O2 instead. >=20 > (MACHINE_ARCH temporarily looks to be amd64, which > gets a -O2 put in CFLAGS instead of -O .) >=20 > ruby seems to go the other direction: with -O2 involved > something builds that fails to run during the build. > With -O involved instead ruby builds fine and produces > a ruby that works. >=20 > (I've not done any analysis to see if the -O2 based > build failure is because of code making assumption > that are not guaranteed vs. if the compiler/linker > is producing something bad from well-defined code.) >=20 >=20 > Bryan Drewery is now aware of the odd -O2 vs. -O > behavior under poudriere-devel/qemu-arm-static/nxb-bin/ > amd64 -> armv7 cross builds and likely it will be > fixed at some point. >=20 > But the existing behavior means that official armv6 and armv7 > port builds that use that poudriere-devel/qemu-arm-static/nxb-bin/ > amd64 -> armv7 cross build structure have been using > -O2 for a long time. This may challenge the use of > -O by default in CFLAGS for armv6 and armv7, in that -O2 > has been under an implicit test for as long as the > cross build structure has been used with share/mk/sys.mk > having the MACHINE_ARCH based selection of -O2 vs. -O . >=20 > mips* may have similar issues to arm* based on what > share/mk/sys.mk does for -O2 vs. -O . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BF4BDC55-AF3E-4423-B76D-2ACC9D433C46>