Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 May 2017 22:13:12 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)
Message-ID:  <C9CB8645-472E-40D9-B193-E977F842C37B@dsl-only.net>
In-Reply-To: <E177E5EE-25EB-4CBA-9C0F-7209AFF30749@dsl-only.net>
References:  <bug-26519-7604@http.bugs.llvm.org/> <bug-26519-7604-UhFFHDCAay@http.bugs.llvm.org/> <0103401A-CEEA-4992-A45E-E60EA151119B@dsl-only.net> <893ECA11-7C80-4D24-A496-92ADC7978A07@FreeBSD.org> <8F708AD1-055E-41BD-BD92-6A87C5FBAA60@dsl-only.net> <78CD5050-2B2B-4213-AF11-7EF744F608B2@dsl-only.net> <E177E5EE-25EB-4CBA-9C0F-7209AFF30749@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2017-May-5, at 6:11 PM, Mark Millard <markmi@dsl-only.net> wrote:

> On 2017-May-5, at 1:22 AM, Mark Millard <markmi@dsl-only.net> wrote:
>=20
>> On 2017-May-5, at 12:45 AM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>=20
>>> On 2017-May-4, at 2:41 PM, Dimitry Andric <dim at FreeBSD.org> =
wrote:
>>>=20
>>>> . . .
>>>> Thanks for the notice.  I have merged the upstream fix into head in
>>>> r317810, and I will MFC it after a few days.
>>>=20
>>> I now have an old PowerMac running:
>>>=20
>>> # uname -paKU
>>> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r317820M  powerpc =
powerpc 1200030 1200030
>>>=20
>>> 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.
>=20
> 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.
>=20
> Both TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64
> have C++ exceptions still messed up.
>=20
>=20
>>> . . .
>>>=20
>>> 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:
>>>=20
>>> ffs_truncate+0x1080
>>>=20
>>> It appears that "call doadump" worked but
>>> I've not looked at what was put in
>>> /var/crash/ .
>>=20
>> If I leave the PowerMac idle running:
>>=20
>> # uname -paKU
>> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r317820M  powerpc =
powerpc 1200030 1200030
>>=20
>> it eventually gets the same ffs_truncate-tied fatal
>> kernel trap, with the same odd lr and the like.
>>=20
>> So, while I cannot directly cause the problem
>> at a specific time, the problem is repeatable.
>>=20
>> 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.
>=20
> The ffs_truncate issue is odd:
>=20
> 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.
>=20
> 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.
>=20
> 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.

=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?C9CB8645-472E-40D9-B193-E977F842C37B>