Bug#886264: firefox-esr: FTBFS on ppc64el

Fri Jan 5 05:00:15 UTC 2018

reassign 886264 binutils
thanks

On Fri, Jan 05, 2018 at 12:03:32PM +0900, Mike Hommey wrote:
> On Wed, Jan 03, 2018 at 03:45:45PM +0000, Julian Gilbey wrote:
> > Package: firefox-esr
> > Version: 52.5.3esr-1
> > 
> > This is the second version of firefox-esr in a row which has a
> > build-failure on ppc64el, meaning that this package cannot migrate to
> > testing.  There was a security fix in 52.5.2esr-1, so it would be very
> > good to attempt to address this.
> > 
> > Sadly, I don't have any idea how the firefox build works or what might
> > be causing the problem, so I don't know how to help fix this one.
> 
> The part of the build that's broken is running parts of Firefox. That
> suggests firefox would not work even if the build succeeded (like, if we
> skipped that part).
> 
> Now, there hasn't been code changes in Firefox since the last time it
> built successfully that could explain this. However, the two failures
> are with a newer version of GCC, which apparently touched PPC codegen.
> 
> IOW, this could be a legitimate GCC bug. Or this could be a legitimate
> GCC bug fix that breaks Firefox somehow. I'm trying to reproduce on a
> porterbox to try and see which it might be (sadly can't install older
> versions of GCC, though).

Another variation is a difference in binutils version, which also has
ppc64 changes.

As for what's crashing, it's happening in one of the first static
initializers (second entry in .init_array).

The code looks like this:
0000000001322050 <._GLOBAL__sub_I_Unified_cpp_media_libstagefright1.cpp>:
 1322050:       7c 08 02 a6     mflr    r0
 1322054:       f8 01 00 10     std     r0,16(r1)
 1322058:       fb c1 ff f0     std     r30,-16(r1)
 132205c:       fb e1 ff f8     std     r31,-8(r1)
 1322060:       f8 21 ff 81     stdu    r1,-128(r1)
 1322064:       3f c2 00 05     addis   r30,r2,5
 1322068:       3b de 25 b8     addi    r30,r30,9656
 132206c:       7f c3 f3 78     mr      r3,r30
 1322070:       48 02 57 ad     bl      134781c <._ZN11stagefright9AAtomizerC2Ev>
(snip)

000000000134781c <._ZN11stagefright9AAtomizerC2Ev>:
 134781c:       7c 08 02 a6     mflr    r0
 1347820:       49 11 10 11     bl      2458830 <0008b362._restgpr0_15>
(snip)

0000000002458830 <0008b362._restgpr0_15>:
 2458830:       e9 e1 ff 78     ld      r15,-136(r1)

0000000002458834 <0008b362._restgpr0_16>:
 2458834:       ea 01 ff 80     ld      r16,-128(r1)

0000000002458838 <0008b362._restgpr0_17>:
 2458838:       ea 21 ff 88     ld      r17,-120(r1)

000000000245883c <0008b362._restgpr0_18>:
 245883c:       ea 41 ff 90     ld      r18,-112(r1)

0000000002458840 <0008b362._restgpr0_19>:
 2458840:       ea 61 ff 98     ld      r19,-104(r1)

0000000002458844 <0008b362._restgpr0_20>:
 2458844:       ea 81 ff a0     ld      r20,-96(r1)

0000000002458848 <0008b362._restgpr0_21>:
 2458848:       ea a1 ff a8     ld      r21,-88(r1)

000000000245884c <0008b362._restgpr0_22>:
 245884c:       ea c1 ff b0     ld      r22,-80(r1)

0000000002458850 <0008b362._restgpr0_23>:
 2458850:       ea e1 ff b8     ld      r23,-72(r1)

0000000002458854 <0008b362._restgpr0_24>:
 2458854:       eb 01 ff c0     ld      r24,-64(r1)

0000000002458858 <0008b362._restgpr0_25>:
 2458858:       eb 21 ff c8     ld      r25,-56(r1)

000000000245885c <0008b362._restgpr0_26>:
 245885c:       eb 41 ff d0     ld      r26,-48(r1)

0000000002458860 <0008b362._restgpr0_27>:
 2458860:       eb 61 ff d8     ld      r27,-40(r1)

0000000002458864 <0008b362._restgpr0_28>:
 2458864:       eb 81 ff e0     ld      r28,-32(r1)

0000000002458868 <0008b362._restgpr0_29>:
 2458868:       e8 01 00 10     ld      r0,16(r1)
 245886c:       eb a1 ff e8     ld      r29,-24(r1)
 2458870:       7c 08 03 a6     mtlr    r0
 2458874:       eb c1 ff f0     ld      r30,-16(r1)
 2458878:       eb e1 ff f8     ld      r31,-8(r1)
 245887c:       4e 80 00 20     blr

The crash occurs on that blr, because lr has a wrong value once here. I
don't know much of ppc, but it seems this is due to the combination of
  2458868:       e8 01 00 10     ld      r0,16(r1)
and
  2458870:       7c 08 03 a6     mtlr    r0

It seems the ld r0,16(r1) is out of place there.

Now, the interesting thing is that the .o the
._ZN11stagefright9AAtomizerC2Ev function comes from looks like:

0000000000000000 <._ZN11stagefright9AAtomizerC1Ev>:
   0:   7c 08 02 a6     mflr    r0
   4:   48 00 00 01     bl      4 <._ZN11stagefright9AAtomizerC1Ev+0x4>
                        4: R_PPC64_REL24        _savegpr0_28

and that has a different address:
0000000002458814 l       .text  0000000000000000              0008b362._savegpr0_28

And the code there looks like:
0000000002458814 <0008b362._savegpr0_28>:
 2458814:       fb 81 ff e0     std     r28,-32(r1)

0000000002458818 <0008b362._savegpr0_29>:
 2458818:       fb a1 ff e8     std     r29,-24(r1)

000000000245881c <0008b362._savegpr0_30>:
 245881c:       fb c1 ff f0     std     r30,-16(r1)

0000000002458820 <0008b362._savegpr0_31>:
 2458820:       fb e1 ff f8     std     r31,-8(r1)
 2458824:       f8 01 00 10     std     r0,16(r1)
 2458828:       4e 80 00 20     blr

FWIW, this matches what the current version in unstable has for the
AAtomizer constructor target. And it has the same code for _restgpr0_29,
so it would seem the problem is limited to that R_PPC64_REL24 relocation
being misapplied.

That would point to a binutils problem.

Mike