Date: Sat, 6 May 2017 02:59:39 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: Dimitry Andric <dim@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: <528DD22A-D880-4BA1-8FA8-BB9CC5004434@dsl-only.net> In-Reply-To: <B6DCAA6B-8721-46F5-B331-E839B830E941@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> <C9CB8645-472E-40D9-B193-E977F842C37B@dsl-only.net> <B6DCAA6B-8721-46F5-B331-E839B830E941@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I'm top posting a find of another stack
handling failure example from the updated
compiler for TARGET_ARCH=3Dpowerpc .]
Bad news: Another code generation error, this
time demonstrated in compiling part of perl5. . .
(I tried to build a port that indirectly
tried build perl5 but perl5's miniperl crashes.)
/usr/obj/portswork/usr/ports/lang/perl5.24/work/perl-5.24.1/numeric.c
has Perl_cast_iv(NV f) for which clang double stores
two different things to one address [24(r1)]. Below
the =3D> lines are the double store, the second
destroying the r30 value that was saved in the first:
Dump of assembler code for function Perl_cast_iv:
0x0196a114 <+0>: mflr r0
0x0196a118 <+4>: stw r0,4(r1)
0x0196a11c <+8>: stwu r1,-32(r1)
0x0196a120 <+12>: stw r31,28(r1)
=3D> 0x0196a124 <+16>: stw r30,24(r1)
0x0196a128 <+20>: mr r31,r1
0x0196a12c <+24>: mfcr r12
=3D> 0x0196a130 <+28>: stw r12,24(r31)
Note: r31 =3D=3D r1 for that second "=3D>" line.
The return code sequence has a similar
problem: two loads from the same address
for what should be distinct values.
Note: r31 =3D=3D r1 here too.
=3D> 0x0196a1bc <+168>: lwz r12,24(r31)
0x0196a1c0 <+172>: lwz r0,36(r1)
0x0196a1c4 <+176>: lwz r31,28(r1)
=3D> 0x0196a1c8 <+180>: lwz r30,24(r1)
0x0196a1cc <+184>: mtcrf 32,r12
0x0196a1d0 <+188>: addi r1,r1,32
0x0196a1d4 <+192>: mtlr r0
0x0196a1d8 <+196>: blr
The Perl_cast_iv source code looks like:
IV
Perl_cast_iv(NV f)
{
if (f < IV_MAX_P1)
return f < IV_MIN ? IV_MIN : (IV) f;
if (f < UV_MAX_P1) {
#if CASTFLAGS & 2
/* For future flexibility allowing for sizeof(UV) >=3D sizeof(IV) =
*/
if (f < UV_MAX_P1_HALF)
return (IV)(UV) f;
f -=3D UV_MAX_P1_HALF;
return (IV)(((UV) f) | (1 + (UV_MAX >> 1)));
#else
return (IV)(UV) f;
#endif
}
return f > 0 ? (IV)UV_MAX : 0 /* NaN */;
}
This sort of thing might explain the
occasional panic that names ffs_truncate
if there is some infrequently used
routine that messes up the stack.
On 2017-May-6, at 12:06 AM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-May-5, at 10:13 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>=20
>> On 2017-May-5, at 6:11 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>=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
> It also happens when busy.
>=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
>>>> . . .
>>>=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.
>>=20
>> I found a bad (old) kernel module in /boot/kernel/
>> and eliminating it appears to have removed the
>> ffs_truncate problem.
>>=20
>> . . .
>=20
> For the ffs_truncate problem I spoke too
> soon: It happened again, this time while
> the old PowerMac was busy.
>=20
> The detail numbers and such were again the
> same.
=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?528DD22A-D880-4BA1-8FA8-BB9CC5004434>