Bug 1295797

Summary: The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le
Product: [Fedora] Fedora Reporter: Jaromír Cápík <jcapik>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: arjun.is, codonell, fweimer, jakub, law, mfabian, ovasik, pfrankli, siddhesh
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64le   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-05 17:37:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1051573    

Description Jaromír Cápík 2016-01-05 13:40:27 UTC 
Description of problem:
The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le for all executables and nothing works. I tried to downgrade to glibc-2.22-6.fc23.ppc64le from a rescue system and that release works correctly. I'm testing that on a P7+ guest.

Version-Release number of selected component (if applicable):
glibc-2.22.90-25.fc24.ppc64le

How reproducible:
always
Comment 1 Florian Weimer 2016-01-05 13:58:04 UTC 
(In reply to Jaromír Cápík from comment #0)
> Description of problem:
> The current rawhide release of glibc causes SIGILL (Illegal instruction) on
> ppc64le for all executables and nothing works. I tried to downgrade to
> glibc-2.22-6.fc23.ppc64le from a rescue system and that release works
> correctly. I'm testing that on a P7+ guest.

Can you provide a backtrace and disassembly showing the faulty instruction?  Thanks.
Comment 2 Jaromír Cápík 2016-01-05 15:34:04 UTC 
I tried that on P8 and it works. Looks like P8 instructions got to the glibc somehow.
Comment 3 Florian Weimer 2016-01-05 16:58:21 UTC 
ld.so crashes in memset, at this instruction:

   0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
   0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
   0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
   0x000000002002d628 <+520>:	add     r12,r12,r0
   0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
   0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
   0x000000002002d634 <+532>:	mtctr   r8
=> 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
   0x000000002002d63c <+540>:	li      r6,16
   0x000000002002d640 <+544>:	li      r7,32
   0x000000002002d644 <+548>:	li      r10,48
Comment 4 Carlos O'Donell 2016-01-05 17:28:17 UTC 
(In reply to Florian Weimer from comment #3)
> ld.so crashes in memset, at this instruction:
> 
>    0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
>    0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
>    0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
>    0x000000002002d628 <+520>:	add     r12,r12,r0
>    0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
>    0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
>    0x000000002002d634 <+532>:	mtctr   r8
> => 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
>    0x000000002002d63c <+540>:	li      r6,16
>    0x000000002002d640 <+544>:	li      r7,32
>    0x000000002002d644 <+548>:	li      r10,48

That's the power8 memset.
Comment 5 Carlos O'Donell 2016-01-05 17:36:06 UTC 
(In reply to Carlos O'Donell from comment #4)
> (In reply to Florian Weimer from comment #3)
> > ld.so crashes in memset, at this instruction:
> > 
> >    0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
> >    0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
> >    0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
> >    0x000000002002d628 <+520>:	add     r12,r12,r0
> >    0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
> >    0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
> >    0x000000002002d634 <+532>:	mtctr   r8
> > => 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
> >    0x000000002002d63c <+540>:	li      r6,16
> >    0x000000002002d640 <+544>:	li      r7,32
> >    0x000000002002d644 <+548>:	li      r10,48
> 
> That's the power8 memset.

I thought this correlated to sysdeps/powerpc/powerpc64/power8/memset.S, but I see now it doesn't quite match up.
Comment 6 Florian Weimer 2016-01-05 17:37:54 UTC 
With proper debugging information, I could resolve the crash site to string/memset.c:54:

50	      /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
51	      xlen = len / (OPSIZ * 8);
52	      while (xlen > 0)
53		{
54		  ((op_t *) dstp)[0] = cccc;
55		  ((op_t *) dstp)[1] = cccc;
56		  ((op_t *) dstp)[2] = cccc;
57		  ((op_t *) dstp)[3] = cccc;
58		  ((op_t *) dstp)[4] = cccc;

So it's GCC which creates POWER8 code.  Per

https://fedoraproject.org/wiki/Architectures/PowerPC#Supported_Architectures

this is expected; Fedora does not support POWER7 and earlier on ppc64le.
Comment 7 Carlos O'Donell 2016-01-05 17:44:36 UTC 
(In reply to Florian Weimer from comment #6)
> With proper debugging information, I could resolve the crash site to
> string/memset.c:54:
> 
> 50	      /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
> 51	      xlen = len / (OPSIZ * 8);
> 52	      while (xlen > 0)
> 53		{
> 54		  ((op_t *) dstp)[0] = cccc;
> 55		  ((op_t *) dstp)[1] = cccc;
> 56		  ((op_t *) dstp)[2] = cccc;
> 57		  ((op_t *) dstp)[3] = cccc;
> 58		  ((op_t *) dstp)[4] = cccc;
> 
> So it's GCC which creates POWER8 code.  Per
> 
> https://fedoraproject.org/wiki/Architectures/PowerPC#Supported_Architectures
> 
> this is expected; Fedora does not support POWER7 and earlier on ppc64le.

That's exactly right. I could not remember if we were still transitionally supporting POWER7, but as of October 2015 all the builders switched to POWER8 for 64-bit and after that point you have to always use POWER8 for ppc64le.