The default bug view has changed. See this FAQ.

IonMonkey: on ARM, Pools and caches violate each others assumptions

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mjrosenb, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
I probably should have noticed this much earlier, but the issue is with this line:
CodeLocationLabel rejoinLabel() const {
      return CodeLocationLabel(initialJump_.raw() + REJOIN_LABEL_OFFSET);
}
This is why in the arm backend, I attempt to do everything through an Instruction class that knows about all of the actual instructions, and has a next() method.
The inline code generated for an IC is an unconditional branch, which means it is a viable place to insert a pool, and is marked as initialJump.  If a pool is in fact placed there, there is no way of making the return point anything other than the instruction following the branch.  Currently, we end up returning to the pool, and running into an illegal instruction shortly thereafter.

There are two solutions that I can think of:
1) don't mark these jumps as viable places to put pools
or
2) rather than blindly adding 4 to the pointer in order to get the return address, use the instruction class, and have it get the "next" instruction, which will skip over the pool entirely.
(Reporter)

Comment 1

5 years ago
decently sure this was triggered, then fixed with one of:
http://hg.mozilla.org/projects/ionmonkey/rev/efe3058e6515
http://hg.mozilla.org/projects/ionmonkey/rev/6ed2a75d11ae
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.