851291 - ARMv6 builds without thumb support are mis-compiled by the GCC in NDK8

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #832942 +++

GCC in NDK8 has a bug that causes it to generate code that causes a bug in Firefox. The GCC bug is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561.

This caused bug 832942. See especially bug 832942 comment 64.

I don't object to the workaround given in bug 832942, however I think a more general solution is needed.

I know we did an analysis of the current code and determined that this bug only currently affects us in one place. But, I think that it is pretty likely that we will add new code and/or modify existing code that will trigger this bug again. And, there is a lot of risk that we many not notice these bugs before release.

I think in the past we used a custom NDK that allowed us to add patches to fix issues in the NDK. Perhaps we should go down that route again, and create a custom NDK that has a GCC with the GCC bug fixed. Obviously, there is risk to this too.

Another option would be to revert to the older NDK that didn't have this bug, which we used for Firefox 19 and earlier. However, my understanding is that this would result in reduced performance so it isn't a no-brainer to do so.

I spoke about akeybl about this and I am marking it tracking per my understanding of his request to do so.

Comment 1

[Mike Hommey [:glandium]]

(In reply to Brian Smith (:bsmith) from comment #0)
> I know we did an analysis of the current code and determined that this bug
> only currently affects us in one place. But, I think that it is pretty
> likely that we will add new code and/or modify existing code that will
> trigger this bug again. And, there is a lot of risk that we many not notice
> these bugs before release.

Considering the bug is triggered on exactly one code line in millions, and how it stops happening with small modifications in the function (like removing some of the code before the line that's broken), I don't think there is a lot of risk. There is risk. Not a lot.

Comment 2

[(not currently active) Ted Mielczarek]

Every version of every compiler has bugs, and we probably hit some of them. I don't think the fact that we hit this one once makes it any riskier than any of the other known GCC bugs.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Workaround given in bug 832942 will have to suffice for FF20, leaving tracking for FF21 if more resources can be spent on a more robust solution here.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Removing this as a dependency for bug 824169. Even if we do fix this (which seems unlikely), it looks like the fix would be something like "use a NDK with a custom-built GCC" rather than "roll back to an older NDK".

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Mark this looks like we can untrack given the low risk and that we can track individual bugs based on their criticality and user impact.  Please renom if you disagree and want to pursue this for an upcoming release.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Agreed

Comment 7

[(not currently active) Ted Mielczarek]

We're not shipping armv6 builds anymore.