Bug 216893 – [MIPS] Broken build after r267371

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Caio Lima]

...

[Caio Lima]

Created attachment 409497 [details]
WIP - Patch

Send patch to check EWS

[Angelos Oikonomopoulos]

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.

[Angelos Oikonomopoulos]

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.

[Angelos Oikonomopoulos]

Created attachment 409580 [details]
Patch

[EWS]

Committed r267535: <https://trac.webkit.org/changeset/267535>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 409580 [details].

[Radar WebKit Bug Importer]

<rdar://problem/69507244>