Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1295797 - The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le
Summary: The current rawhide release of glibc causes SIGILL (Illegal instruction) on p...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: ppc64le
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2016-01-05 13:40 UTC by Jaromír Cápík
Modified: 2016-02-01 02:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-05 17:37:54 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.