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:
> 
>> 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=213778 .]
>>> 
>>> 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. . .
>>> 
>>> In truss's enter_syscall there is (from a live gdb on truss, after the 
>>> segmentation fault):
>>> 
>>> 380         t->cs.name = sysdecode_syscallname(t->proc->abi->abi, 
>>> t->cs.number);
>>> 381         if (t->cs.name == NULL)
>>> (gdb) 
>>> 382                 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
>>> 383                     t->proc->abi->type, t->cs.number);
>>> 384 
>>> 385         sc = get_syscall(t->cs.name, narg);
>>> 386         t->cs.nargs = sc->nargs;
>>> 387         assert(sc->nargs <= nitems(t->cs.s_args));
>>> 388 
>>> 389         t->cs.sc = sc;
>>> 
>>> (gdb) print *t
>>> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, 
>>> tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 
>>> 580828064, args = 0x2061b0c0, nargs = 0, 
>>>   s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 
>>> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>>> 
>>> (gdb) print sc
>>> $3 = (struct syscall *) 0x0
>>> 
>>> So line 386 listed above gets a segmentation fault for sc->nargs when 
>>> t->cs.name is a NULL pointer: sc ends up NULL.
>>> 
>>> Looking at the two things that the fprintf on lines 382 and 383 would 
>>> report:
>>> 
>>> (gdb) print t->proc->abi->type
>>> $4 = 0x10166 "FreeBSD ELF32"
>>> 
>>> (gdb) print t->cs.number
>>> $5 = 580828064
>>> 
>>> (gdb) print narg
>>> $6 = 0
>>> 
>>> (that last is for context for the get_syscall arguments).
>>> 
>>> FYI: 580828064 = 0x229EBBA0
>> 
>> I have a patchset I have tested some in a git branch that I believe fixes 
>> handling of
>> unknown system calls.  Please try this:
>> 
>> https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
>> 
>> (Add .diff to get a diff you can apply with patch)
>> 
>> -- 
>> John Baldwin
> 
> Sorry it took so long to try the build. . .
> 
> 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):
> 
>> --- main.o ---
>> cc -target armv6-gnueabihf-freebsd11.0 
>> --sysroot=/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=gnu99 -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 
>> -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
>> 
>> make[4]: stopped in /usr/src/usr.bin/truss
>> 1 error
> 
> 
> 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> .)
> 
> Which way do you want the C99 typing to be handled for this: native C99 with 
> no <stdbool.h> required? Use <stdbool.h> ?
> 
> 
> Side note:
> 
> 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.
> 
> ===
> 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=cortex-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=213785 ]

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 => /usr/local/lib/libmpc.so.3 (0x21aff000)
        libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x21b25000)
        libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x21bba000)
        libz.so.6 => /lib/libz.so.6 (0x21c5b000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x21c77000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x21d1d000)
        libm.so.5 => /lib/libm.so.5 (0x21d3f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x21d62000)
        libc.so.7 => /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+=BOOTSTRAP

for the BPI-M3 lang/gcc6 build I used:

OPTIONS_FILE_SET+=BOOTSTRAP

This might explain why I did not see a problem on the rpi2 historically.


===
Mark Millard
markmi at dsl-only.net


_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to