On 2017-May-5, at 1:22 AM, Mark Millard <mar...@dsl-only.net> wrote: > On 2017-May-5, at 12:45 AM, Mark Millard <markmi at dsl-only.net> wrote: > >> On 2017-May-4, at 2:41 PM, Dimitry Andric <dim at FreeBSD.org> wrote: >> >>> . . . >>> Thanks for the notice. I have merged the upstream fix into head in >>> r317810, and I will MFC it after a few days. >> >> I now have an old PowerMac running: >> >> # uname -paKU >> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc powerpc >> 1200030 1200030 >> >> where buildworld was via clang 4 (an amd64->powerpc >> cross build). Even the classic tiny program that >> previously showed C++ exception handling was broken >> and would crash the program now works when >> re-compiled and re-linked. Commands that were >> previous broken now work.
I messed up and accidentally installed the gcc 4.2.1 world that I had also built. This is why C++ exceptions appeared to be working for powerpc. Both TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 have C++ exceptions still messed up. >> (But my testing is nearly minimal at this point.) >> >> The kernel is from gcc421. >> >> >> >> I did try booting a kernel built by system-clang 4 >> and it got to: >> >> exec /sbin/init: error 13 >> >> and a later alignment exception at sf_buf_alloc+0x260 >> >> (Hand transcribed screen information.) >> >> This is the same as the last time that I tried >> such. The exception involved: >> >> exec_map_first_page >> kern_execve >> sys_execve >> start_init >> fork_exit >> fork_trampoline >> >> >> >> For the gcc 4.2.1 based kernel boot I have >> had one odd fatal kernel trap (0x903a64a, >> "unknown") where the lr showed 0x907f . It >> reported being stopped at: >> >> ffs_truncate+0x1080 >> >> It appears that "call doadump" worked but >> I've not looked at what was put in >> /var/crash/ . > > If I leave the PowerMac idle running: > > # uname -paKU > FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc powerpc > 1200030 1200030 > > it eventually gets the same ffs_truncate-tied fatal > kernel trap, with the same odd lr and the like. > > So, while I cannot directly cause the problem > at a specific time, the problem is repeatable. > > I did not build the kernel with a so-called > "red-zone" to work around any stack-operation > ordering problems that might still be around. > But I do not know that such is involved here. > It may be a while before I manage to get that > much of an analysis done. The ffs_truncate issue is odd: A) It was gcc 4.2.1 based for both kernel and world. B) I built a gcc 4.2.1 based debug kernel and installed it but that does not get the problem. I sam trying the gcc 4.2.1 debug kernel with the system clang 4 world now and will later switch to the gcc 4.2.1 non-debug kernel to see what happens. But being a pure gcc 4.2.1 environment originally suggests that the ffs_truncate issue is not clang-toolchain related. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
