861208 - Assertion failure: false (unsupported relocation), at js/src/ion/arm/Assembler-arm.cpp:798

Status: RESOLVED DUPLICATE of bug 1020834

(Core :: JavaScript Engine, defect)

Description

[Douglas Crosher [:dougc]]

Hit this assertion failure in ARMv6 testing.  No simple example, but perhaps there is enough to give a clue.

The function getPtr32Target appears to expect an instruction sequence with a constant pointer, but the actual instruction is a branch.

Could it be that BaselineCompiler emitted an instruction with a constant, but the constant pool overflowed and it emitted a branch at the location?

If so then a possible solution would be to follow the branch and find the instruction with the pointer?


Program received signal SIGSEGV, Segmentation fault.
0x00b20cf4 in js::ion::Assembler::getPtr32Target<js::ion::InstructionIterator> (start=0xbec9426c, dest=0xbec94268, style=0xbec94264) at js/src/ion/arm/Assembler-arm.cpp:798
798	    JS_NOT_REACHED("unsupported relocation");
(gdb) back
#0  0x00b20cf4 in js::ion::Assembler::getPtr32Target<js::ion::InstructionIterator> (start=0xbec9426c, dest=0xbec94268, style=0xbec94264) at js/src/ion/arm/Assembler-arm.cpp:798
#1  0x00b1e3c4 in js::ion::Assembler::patchDataWithValueCheck (label=..., newValue=..., expectedValue=...) at js/src/ion/arm/Assembler-arm.cpp:2525
#2  0x00c1330c in js::ion::BaselineCompiler::compile (this=0xbec94480) at js/src/ion/BaselineCompiler.cpp:156
#3  0x00845a84 in BaselineCompile (cx=0x1f180e0, script=...) at js/src/ion/BaselineJIT.cpp:218
#4  0x0084624c in js::ion::CanEnterBaselineJIT (cx=0x1f180e0, scriptArg=0xb67291a8, fp=0xb6938090, newType=false) at js/src/ion/BaselineJIT.cpp:283
#5  0x00256444 in js::Interpret (cx=0x1f180e0, entryFrame=0xb6938090, interpMode=js::JSINTERP_NORMAL, useNewType=false) at js/src/jsinterp.cpp:1461

Comment 1

[Douglas Crosher [:dougc]]

Attachment: Hack patch to deal with the some instruction sequences that show up in ARMv6 asm.js jits-tests.

Here's a quick patch that seems to deal with the immediate failures in the asm.js jit-tests.  The patch just detects a branch instruction and follows it.  While this helps narrow down the problem, more analysis is suggested.

Comment 2

[Douglas Crosher [:dougc]]

Here's another ARMv6 failure that appears to be related so is just noted along with this bug for now.  The compiled code crashes with a SIGSEV when run.  It looks like another constant pool issue that shows up because the call sequence can not use an immediate constant on the ARMv6.

Assertion failure: nextOffset().getOffset() - offset.offset() == ToggledCallSize(), at /home/src/b2g/src-asmjs4/js/src/ion/arm/MacroAssembler-arm.cpp:3347

One example that reproduces this is the debug/Environment-find-06.js test with --ion-eager and with a build that uses the ARMv6 instructions.

Comment 3

[Douglas Crosher [:dougc]]

This bug might be contributing the crashes noted in Bug 863685.

One potential solution to explore is to keep a small reserve in the constant pools and to use this reserve when emitting an instruction sequence that is not expected to have a constant pool flush and branch at the start or within.  From the issues seen it would appear to be ok to flush the pools at the end of the instruction sequence if the reserve has become full.

Comment 4

[Douglas Crosher [:dougc]]

Attachment: Handle some relocation sequences that show up in ARMv6 code.

Rebased to apply after the assembler buffer rewrite patch in bug 760642 for which it appears to be needed now even for ARMv7 code.

Comment 5

[Douglas Crosher [:dougc]]

Attachment: Handle some relocation sequences that show up.

Add a similar patch to ma_movPatchable, fixing a crash noted in bug 760642.

Comment 6

[Douglas Crosher [:dougc]]

Landed on user repo:
https://hg.mozilla.org/users/dtc-moz_scieneer.com/asmbuffer/rev/2a3dfe18cb27

Comment 7

[Douglas Crosher [:dougc]]

Comment on attachment 8375538 [details] [diff] [review]
Handle some relocation sequences that show up.

The need to work around these branches has become common, and perhaps more cases need to be handled?

Any suggestions on how to refactor this?

Move the logic into the instruction iterator?

Comment 8

[Douglas Crosher [:dougc]]

Should be fixed in bug 1020834.