Comment 113 for bug 908508

Revision history for this message
In , Landry-openbsd (landry-openbsd) wrote :

(In reply to David Mandelin from comment #102)
> This is getting really confusing--I feel like I need to back up a few steps.

Yes, i'm also confused.

> 1. First off, do you still need to leave out the executableAllocators in
> jscntxt.h? If you have the JITs now, then it seems like you don't even need
> to patch jscntxt.h. I'm going to assume you do, and continue, but if we
> don't need to do anything, that would be great.

There are platforms where there's no JIT (and hence no ExecutableAllocator), for example sparc64 & macppc/sysv abi. So we have to #ifdef ENABLE_ASSEMBLER out the execAlloc uses.

> 2. Second, if possible, it'd be nice to do something small and simple that
> just fixes the immediate problem. The immediate problem, IIUC, is that you
> can't have the executableAllocators in JSContext, and #ifdef
> ENABLE_ASSEMBLER in jscntxt.h doesn't work. So, what about just providing a
> dummy class for ExecutableAllocator on SPARC? Would that work? You could put
> it in a .cpp file guarded by !ENABLE_ASSEMBLER.

To me, the immediate problem is that i've a diff that works, but it breaks some tests in subtle ways just because ENABLE_ASSEMBLER=1 is not propagated anymore under shell/ with my diff.

ExecutableAllocator.h has the arch-dependant machinery, and it #errors out on the archs we care about in this bug report.. because (at least!) there's no implementation for 'cacheFlush', which seems to require writing some low-level asm, and i have no idea if it can be made a nop.

x86/x86_64 provides an empty implementation, but iirc i tried adding ppc to also use that empty implem and it failed to build.