On 2017-May-5, at 6:11 PM, Mark Millard <mar...@dsl-only.net> wrote:
> 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. > > >>> . . . >>> >>> 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. I found a bad (old) kernel module in /boot/kernel/ and eliminating it appears to have removed the ffs_truncate problem. And even more good news: buildworld buildkernel makes extensive use of signals and its failure is how I discovered the original stack handling problems for powerpc (the ABI violations). I used to have to patch in so-called "red zone" handling to avoid the issue. No more: a running a kernel that was built without a "red zone" and running a world based on clang now allows buildworld buildkernel to complete just fine: no evidence of ABI violations in the world code that is executed. Going the other direction: I've conformed that clang still generates C++ programs that can not handle thrown exceptions. Both powerpc and powerpc64 are this way. The only other area with an issue that I know of is the exec /sbin/init failure that prevents using the clang based kernel for powerpc. (This is based on the system binutils for powerpc and devel/*binutils for powerpc64 instead of lld and such. lld has its own problems for these targets.) I already build and run powerpc64 kernels built by clang. That has been true for a while. === 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"
