Oh, sorry! I didn't update it to my latest test case:(

Here is:

====== x = 0

for i = 1, 100 do x = tostring(i) end

y = "101"

assert(x == y, "Got " .. x .. ", expect " .. y) ======

It runs into Segment Fault instead of giving assertion error.

I'll take a look at the SPS_FIXED related issue.

On 29 July 2016 at 22:05, Charles Baylis charles.baylis@linaro.org wrote:

On 29 July 2016 at 10:12, Zhongwei Yao zhongwei.yao@linaro.org wrote:

...

Hi, all, I run into Segment Fault in:

======

x = 0

for i = 1, 100 do x = tostring(i) end

y = "101"

======

And it turns out the JITed code overwrites native stack position at trace head. It can be walked around by set SPS_FIXED to 0.

The JITed code is doing register spill and assuming there is "2 fixed

spill

...

slots" (defined by SPS_FIXED). But there seems no "fixed spill slots" in arm64 interpreter implementation. Is it true? Could anyone provide some

info

...

of aarch64 frame layout?

Any input will help! Thanks.

I've tried your test case here, and it works ok for me. I added print(x) and print(y) and I get 100 and 101 as expected. Do you have an old tree or some local patches?

I added the SPS_FIXED values very early in the port, but they are only copy-and-pasted, so are quite likely to be wrong. Any investigation you can do is valuable :)

There are a few comments about LuaJIT frame layout in lj_frame.h, but I haven't found any clear explanations about how it really works, and there a few hard-coded constants in the interpreter which may be tied to the frame layout.

Charles

Hi, Stefan, Thanks for your reply! I'll take a look at and will report anything useful.

On 1 August 2016 at 16:48, Stefan Pejic stefan.pejic@rt-rk.com wrote:

Hey Zhongwei,

If you want to take a look at ARM64 frame layout you can find it in vm_arm64.dasc, around line 90 (or in lj_frame.h, since they have to match).

Now, SPS_FIXED basically says to JIT that it can use part of the interpreter's frame. If we take a look at 32-bit ARM (vm_arm.dasc:60), we can see that it has 2 temporary slots at the top of the stack, which don't need to be preserved. But on ARM64, there is no temporary slot on top of stack, which (I would say) means that SPS_FIXED should be 0.

ARM64 does actually have one 8-byte temporary slot, but it's deep in stack (sp+184), which doesn't make it usable for JIT. I guess that we could rearrange the frame and put it to the top of the frame, but I'm not sure how smart is that. Mike Pall probably put it there for a reason.

Anyway, there might be more to this than what I said. I encourage you to take a better look

Stefan

On Mon, 1 Aug 2016 09:02:47 +0800 Zhongwei Yao zhongwei.yao@linaro.org wrote:

...

Oh, sorry! I didn't update it to my latest test case:(

Here is:

====== x = 0

for i = 1, 100 do x = tostring(i) end

y = "101"

assert(x == y, "Got " .. x .. ", expect " .. y)

It runs into Segment Fault instead of giving assertion error.

I'll take a look at the SPS_FIXED related issue.

On 29 July 2016 at 22:05, Charles Baylis charles.baylis@linaro.org wrote:

...

On 29 July 2016 at 10:12, Zhongwei Yao zhongwei.yao@linaro.org wrote:

...

Hi, all, I run into Segment Fault in:

======

x = 0

for i = 1, 100 do x = tostring(i) end

y = "101"

======

And it turns out the JITed code overwrites native stack position at trace head. It can be walked around by set SPS_FIXED to 0.

The JITed code is doing register spill and assuming there is "2 fixed

spill

...

slots" (defined by SPS_FIXED). But there seems no "fixed spill slots" in arm64 interpreter implementation. Is it true? Could anyone provide some

info

...

of aarch64 frame layout?

Any input will help! Thanks.

I've tried your test case here, and it works ok for me. I added print(x) and print(y) and I get 100 and 101 as expected. Do you have an old tree or some local patches?

I added the SPS_FIXED values very early in the port, but they are only copy-and-pasted, so are quite likely to be wrong. Any investigation you can do is valuable :)

There are a few comments about LuaJIT frame layout in lj_frame.h, but I haven't found any clear explanations about how it really works, and there a few hard-coded constants in the interpreter which may be tied to the frame layout.

Charles