Date: Sat, 29 Oct 2016 03:22:25 -0700 From: Mark Millard <markmi@dsl-only.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Message-ID: <05266324-67D0-4487-BF94-58B831C79F5B@dsl-only.net> In-Reply-To: <C3B549C5-AF5B-458C-961D-9C45C63218F5@dsl-only.net> References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> <C3B549C5-AF5B-458C-961D-9C45C63218F5@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Oct-28, at 4:02 PM, Mark Millard <markmi at dsl-only.net> wrote: > On 2016-Oct-28, at 7:29 AM, John Baldwin <jhb at freebsd.org> wrote: >=20 >> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >>> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>>=20 >>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>>=20 >>> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>>=20 >>> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >>> 381 if (t->cs.name =3D=3D NULL) >>> (gdb)=20 >>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >>> 383 t->proc->abi->type, t->cs.number); >>> 384=09 >>> 385 sc =3D get_syscall(t->cs.name, narg); >>> 386 t->cs.nargs =3D sc->nargs; >>> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >>> 388=09 >>> 389 t->cs.sc =3D sc; >>>=20 >>> (gdb) print *t >>> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc = =3D 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, = name =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >>> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>>=20 >>> (gdb) print sc >>> $3 =3D (struct syscall *) 0x0 >>>=20 >>> So line 386 listed above gets a segmentation fault for sc->nargs = when t->cs.name is a NULL pointer: sc ends up NULL. >>>=20 >>> Looking at the two things that the fprintf on lines 382 and 383 = would report: >>>=20 >>> (gdb) print t->proc->abi->type >>> $4 =3D 0x10166 "FreeBSD ELF32" >>>=20 >>> (gdb) print t->cs.number >>> $5 =3D 580828064 >>>=20 >>> (gdb) print narg >>> $6 =3D 0 >>>=20 >>> (that last is for context for the get_syscall arguments). >>>=20 >>> FYI: 580828064 =3D 0x229EBBA0 >>=20 >> I have a patchset I have tested some in a git branch that I believe = fixes handling of >> unknown system calls. Please try this: >>=20 >> = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >>=20 >> (Add .diff to get a diff you can apply with patch) >>=20 >> --=20 >> John Baldwin >=20 > Sorry it took so long to try the build. . . >=20 > I got a compile failure for use of bool in my stable/11 context for = the BPI-M3 build that the truss problem was discovered with (quoting the = build log below): >=20 >> --- main.o --- >> cc -target armv6-gnueabihf-freebsd11.0 = --sysroot=3D/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp = -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe = -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD = -MF.depend.main.o -MTma >> in.o -std=3Dgnu99 -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs=20 >> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/usr.bin/truss/main.c -o main.o >> In file included from /usr/src/usr.bin/truss/main.c:53: >> /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name = 'bool' >> bool unknown; /* Uknown system call */ >> ^ >> 1 error generated. >> *** [main.o] Error code 1 >>=20 >> make[4]: stopped in /usr/src/usr.bin/truss >> 1 error >=20 >=20 > In C99 bool is a macro from <stdbool.h> and _Bool is the C99 type = itself. So apparently <stdbool.h> (or an equivalent) was not directly or = indirectly included. (The macros true and false and = __bool_true_false_are_defined are also from <stdbool.h> .) >=20 > Which way do you want the C99 typing to be handled for this: native = C99 with no <stdbool.h> required? Use <stdbool.h> ? >=20 >=20 > Side note: >=20 > I'll see about getting my normal stable/11 build environment going for = the BPI-M3 instead of using the crochet from my first-time build for the = target. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net [Once I got back to this test yet again I arbitrarily added a #include = <stdbool.h> to allow truss to build during buildworld.] The way I normally build (instead of crochet) did not get the original = cc1 problem in its original form. So as of yet I've not managed to = reproduce the test case accurately: Back to crochet. I will note that in my "with debug symbols" and -mcpu=3Dcortex-a7 style = of buildworld buildkernel type of boot context I got an explicit message = in the xgcc/cc1 test that may indicate the original problem for cc1: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: Undefined = symbol "__aeabi_uidiv" [bugzilla https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213785 ] At this stage in trying to bootstrap lang/gcc6 as the first gcc compiler = on the BPi-M3: # ldd /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: libmpc.so.3 =3D> /usr/local/lib/libmpc.so.3 (0x21aff000) libmpfr.so.4 =3D> /usr/local/lib/libmpfr.so.4 (0x21b25000) libgmp.so.10 =3D> /usr/local/lib/libgmp.so.10 (0x21bba000) libz.so.6 =3D> /lib/libz.so.6 (0x21c5b000) libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x21c77000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x21d1d000) libm.so.5 =3D> /lib/libm.so.5 (0x21d3f000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x21d62000) libc.so.7 =3D> /lib/libc.so.7 (0x21e00000) So /usr/local/lib/ is not yet providing gcc's own library of primitives = for xgcc or cc1 to use and when FreeBSD is missing something = like__aeabi_uidiv that xgcc/cc1 expects to use there could then be = problems: # ls -l /usr/local/lib total 127288 -r-xr-xr-x 1 root wheel 10168 Oct 25 07:39 bindtextdomain.so drwxr-xr-x 2 root wheel 512 Oct 25 05:57 gettext -rw-r--r-- 1 root wheel 72026 Oct 25 05:40 libasprintf.a lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so -> = libasprintf.so.0.0.0 lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so.0 -> = libasprintf.so.0.0.0 -rwxr-xr-x 1 root wheel 64717 Oct 25 05:40 libasprintf.so.0.0.0 -rw-r--r-- 1 root wheel 58917550 Oct 25 08:52 libbfd.a -rwxr-xr-x 1 root wheel 4421893 Oct 25 05:56 = libgettextlib-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextlib.so -> = libgettextlib-0.19.8.1.so -rw-r--r-- 1 root wheel 1611908 Oct 25 05:56 libgettextpo.a lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so -> = libgettextpo.so.0.5.4 lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so.0 -> = libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1134132 Oct 25 05:56 libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1005228 Oct 25 05:56 = libgettextsrc-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextsrc.so -> = libgettextsrc-0.19.8.1.so -rw-r--r-- 1 root wheel 2935784 Oct 25 08:01 libgmp.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so -> = libgmp.so.10.1.3 lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so.10 -> = libgmp.so.10.1.3 -rwxr-xr-x 1 root wheel 1709666 Oct 25 08:01 libgmp.so.10.1.3 -rw-r--r-- 1 root wheel 1112250 Oct 25 08:01 libgmpxx.a lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so -> = libgmpxx.so.4.3.3 lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so.4 -> = libgmpxx.so.4.3.3 -rwxr-xr-x 1 root wheel 657771 Oct 25 08:01 libgmpxx.so.4.3.3 -rw-r--r-- 1 root wheel 238518 Oct 25 05:40 libintl.a lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so -> = libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so.8 -> = libintl.so.8.1.5 -rw-r--r-- 1 root wheel 157207 Oct 25 05:40 libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 12 Oct 25 05:40 libintl.so.9 -> = libintl.so.8 -rw-r--r-- 1 root wheel 565968 Oct 25 09:02 libmpc.a lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so -> = libmpc.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so.3 -> = libmpc.so.3.0.0 -rwxr-xr-x 1 root wheel 346999 Oct 25 09:02 libmpc.so.3.0.0 -rw-r--r-- 1 root wheel 2053300 Oct 25 08:05 libmpfr.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so -> = libmpfr.so.4.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so.4 -> = libmpfr.so.4.1.5 -rwxr-xr-x 1 root wheel 1294011 Oct 25 08:05 libmpfr.so.4.1.5 -rw-r--r-- 1 root wheel 38488604 Oct 25 08:52 libopcodes.a -rw-r--r-- 1 root wheel 7155654 Oct 25 05:36 libpkg.a lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so -> = libpkg.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so.3 -> = libpkg.so.3.0.0 -rwxr-xr-x 1 root wheel 5621424 Oct 25 05:36 libpkg.so.3.0.0 drwxr-xr-x 4 root wheel 512 Oct 25 07:37 perl5 Part of the issue may be that unlike my usual procedure for gcc* builds: OPTIONS_FILE_UNSET+=3DBOOTSTRAP for the BPI-M3 lang/gcc6 build I used: OPTIONS_FILE_SET+=3DBOOTSTRAP This might explain why I did not see a problem on the rpi2 historically. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05266324-67D0-4487-BF94-58B831C79F5B>