Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 May 2017 11:54:07 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 206990] powerpc (32-bit), projects/clang380-import vs. 11.0-CURRENT's sendsig: need to avoid signal delivery trashing the stack and so causing SIGSEGV
Message-ID:  <bug-206990-8-aQYit3pliJ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-206990-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-206990-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206990

--- Comment #8 from Mark Millard <markmi@dsl-only.net> ---
(In reply to commit-hook from comment #7)

It appears that this fix was necessary but not
sufficient 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 */;
}


I've reported this in llvm's bugzilla, reopening
the report about ABI-stack-handling violations.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206990-8-aQYit3pliJ>