1041519 - ARM Simulator bustage when trunk merges to Aurora

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

I'm not sure if this matters from a TBPL standpoint (not sure if ARM simulator builds are even run on the release branches), but I'm pretty sure this will at least break the fuzzers post-uplift.

https://tbpl.mozilla.org/php/getParsedLog.php?id=44245370&tree=Try

testJitMoveEmitterCycles.o: In function `js::jit::Simulator::set_s_register_from_float(int, float)':
/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: undefined reference to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)'
/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: undefined reference to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)'
/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: undefined reference to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)'
/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: undefined reference to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)'
/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: undefined reference to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)'
testJitMoveEmitterCycles.o:/builds/slave/try_lx-d_sm-arm-sim-0000000000/src/js/src/jsapi-tests/../jit/arm/Simulator-arm.h:131: more undefined references to `void js::jit::Simulator::setVFPRegister<float, 1>(int, float const&)' follow
/usr/bin/ld: jsapi-tests: hidden symbol `_ZN2js3jit9Simulator14setVFPRegisterIfLi1EEEviRKT_' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Here are the changes made to simulate the uplift on Try:
https://hg.mozilla.org/try/rev/1ef14eff8c78

Comment 2

[Jan de Mooij [:jandem]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4][PTO 21-July] from comment #0)
> I'm not sure if this matters from a TBPL standpoint (not sure if ARM
> simulator builds are even run on the release branches), but I'm pretty sure
> this will at least break the fuzzers post-uplift.

The simulator is also very useful when backporting patches.

Comment 3

[Marty Rosenberg [:mjrosenb]]

Strange.  I thought I fixed this by explicitly instantiating these functions.  Maybe the signatures were slightly different.

Comment 4

[Douglas Crosher [:dougc]]

Attachment: Instantiate setVFPRegister for use by the jsapi-tests.

These need instantiating for Aurora 33, and might as well land on 34 too. Only the 'float' instance is really needed for Aurora, but it seems prudent to instantiate the 'double' case too.

Comment 5

[Marty Rosenberg [:mjrosenb]]

Comment on attachment 8463753 [details] [diff] [review]
Instantiate setVFPRegister for use by the jsapi-tests.

Review of attachment 8463753 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch.  I tried to get this to fail locally, and wasn't able to reproduce.

Comment 6

[Douglas Crosher [:dougc]]

Here's a successful try build of the arm simulator (Aurora):
https://tbpl.mozilla.org/?tree=Try&rev=9ea558e1c440

This patch has also been tested locally and resolved the build failure.

This was needed to fix the Aurora build, but should land on the trunk too.
Is it necessary to request approval to land this on Aurora?

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Douglas Crosher [:dougc] from comment #6)
> Is it necessary to request approval to land this on Aurora?

No it can land with a=NPOTB because it only touches the ARM simulator so it does not affect the official builds in any way.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Thanks!

https://hg.mozilla.org/integration/mozilla-inbound/rev/126614591bec
https://hg.mozilla.org/releases/mozilla-aurora/rev/b32f17c988ad

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/126614591bec

Comment 10

[Ada [:adalucinet]]

Based on the qa+ flag, could you please provide STR in order to reproduce and verify this fix? Thanks in advance.

Comment 11

[Douglas Crosher [:dougc]]

(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #10)
> Based on the qa+ flag, could you please provide STR in order to reproduce
> and verify this fix? Thanks in advance.

This one was a failure during compilation. It's not a defect in the product. If the code compiles without producing the reported error then the issue has been resolved.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

This was verified the day that 33 hit beta and the arm builds didn't burn.