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