Last Comment Bug 728850 - IonMonkey: on ARM, Pools and caches violate each others assumptions
: IonMonkey: on ARM, Pools and caches violate each others assumptions
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: ARM Linux
-- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2012-02-20 05:26 PST by Marty Rosenberg [:mjrosenb]
Modified: 2012-07-27 18:55 PDT (History)
0 users
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Marty Rosenberg [:mjrosenb] 2012-02-20 05:26:32 PST
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
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.
Comment 1 User image Marty Rosenberg [:mjrosenb] 2012-07-27 18:55:12 PDT
decently sure this was triggered, then fixed with one of:

Note You need to log in before you can comment on or make changes to this bug.