| 12 Nov 2024 |
 nbp | emily: I can forward questions if needed.
The whole concept is kind of fun. Some components are compiled as WebAssembly before being compiled to assembly and embedded in the binary. There is no WebAssembly interpreted/jitted at the end, but all the sand-boxing of the execution remains around the embedded component. This is a security feature to isolate components of Firefox.
| 10:51:40 |
| nbp | unless you are referring to WASI as a target, in which case I am not aware, but I can still forward questions. | 10:53:53 |
 emily | In reply to @nbp:mozilla.org
emily: I can forward questions if needed.
The whole concept is kind of fun. Some components are compiled as WebAssembly before being compiled to assembly and embedded in the binary. There is no WebAssembly interpreted/jitted at the end, but all the sand-boxing of the execution remains around the embedded component. This is a security feature to isolate components of Firefox.
so here's my understanding of the situation:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1905251 was opened for an LLVM 19-related regression in the WASI build
- https://hg.mozilla.org/integration/autoland/rev/23a9f6555c7c was merged as a workaround
- it was backed out in https://hg.mozilla.org/mozilla-central/rev/b8a794387245 because it was fixed upstream
- from my digging, it seems pretty clear that the upstream fix was https://github.com/llvm/llvm-project/pull/97451
- but we seem to get the same error even in the latest LLVM 19 released months after that fix
- re-applying the previous Firefox workaround fixes it
| 13:49:39 |
| emily | which makes me wonder "are we absolutely sure it was tested that the fix actually fixed it?" | 13:49:51 |
| emily | but – Nixpkgs compilers are weird. it's also possible we're messing it up somehow and it's our fault | 13:50:02 |
| nbp | have the changes stick in LLVM, or did they got backed out of LLVM? | 13:56:14 |
 hexa | I can see the changes are still applied in 19.1.3 | 14:07:51 |
| emily | I didn't see any indication of revert | 14:12:07 |
| emily | the Mozilla bug does not directly link the LLVM change, but the circumstances, error message, and workaround are an exact match | 14:12:23 |
| emily | and it seems like it should directly fix the build error I saw | 14:12:33 |
| emily | so I'm wondering if upstream LLVM fix is broken and Mozilla didn't fully test it (understandable since they haven't yet upgraded their actual builders to LLVM 19 yet AFAIK), or if somehow we are breaking things with our weirdness | 14:12:57 |
| emily | it is no longer urgent since I reapplied the workaround on our LLVM 19 branch, but it is concerning | 14:13:11 |
| nbp | Mozilla maintains its own version of LLVM, maybe there is another fix that went in that has not been upstreamed? | 14:21:20 |
| nbp | * Mozilla maintains its pinned version of LLVM, maybe there is another fix that went in that has not been upstreamed? | 14:21:38 |
| emily | they said "Backed out as requested by owner because the upstream issue was fixed." | 14:30:41 |
| emily | and AFAIK the Mozilla builders are not yet on LLVM 19 (https://bugzilla.mozilla.org/show_bug.cgi?id=1925199) | 14:30:50 |
| emily | and the timing of the backout was very close to the LLVM PR I linked | 14:30:59 |
| emily | so I would be surprised were that the case | 14:31:03 |
| nbp | in this change, I see https://phabricator.services.mozilla.com/differential/changeset/?ref=8497643 , would that help? | 14:46:06 |
