...
Created attachment 409497 [details] WIP - Patch Send patch to check EWS
OK this should fix it. While the bug in LabelReference.mapChildren is obvious (it just eats up the offset when returning a new LabelReference, essentially setting it to zero), it wasn't clear to us why this bug didn't affect any of the other architectures. I've only compared with X86_64 but suspect the same explanation applies to archs other than MIPS. What happens is that the AST from the parser only contains LabelReference(label, 0) + AddImmediates and AddImmediates.fold correctly constructs a LabelReference with an offset by calling LabelReference.plusOffset. We do call mapChildren on those on X86_64, however only in the context of a call to isASTErroneous which (somewhat ironically) simply checks the existence of Error nodes and discards the rest of the transformed AST, which would have the erroneous LabelReference nodes. However, on MIPS, mapChildren gets called in the lowering stage too, specifically: getModifiedListMIPS -> assignRegistersToTemporaries -> replaceTemporariesWithRegisters -> mapChildren and there the (erroneous) result is getting used, resulting in all LabelReference nodes having an offset of zero.
With regard to the second hunk of the patch, there was a minor thinko in the initial fix; we need to look up the label in the GOT, not the computed address. Now that we have a good explanation for why the LabelReference.mapChildren issue is not biting other architectures, I think this is good to go in.
Created attachment 409580 [details] Patch
Committed r267535: <https://trac.webkit.org/changeset/267535> All reviewed patches have been landed. Closing bug and clearing flags on attachment 409580 [details].
<rdar://problem/69507244>