Running VS Code on RISC-V SBC

[ksco]

Electron-based apps seem still not working in general.

Logs for VS Code:

8521|SIGSEGV @0x3fd3629072 (strlen (/lib/riscv64-linux-gnu/libc.so.6)) (x64pc=0x2f0b53/???:"???", rsp=0x10b37c818), for accessing (nil) (code=1)
RAX:0x000000010b37ca40 RCX:0xffffffffffffffff RDX:0x0000000000000001 RBX:0x0000000000000100 
RSP:0x000000010b37c818 RBP:0x000000010b37c830 RSI:0x0000000000000100 RDI:0x000000010b37c910 
 R8:0x00000001029569a3  R9:0x000000010b37c8f0 R10:0x0000000000000017 R11:0x5555555555555555 
R12:0x00000001026e5303 R13:0x0000000000000000 R14:0x000000010b37c910 R15:0x000000010b37c910 
Segmentation fault

[ksco]

Any ideas on how to debug this? It would be great if Electron apps would work.

[ptitSeb]

Try with BOX64_ROLLING_LOG=1 to see last call at the segfault, maybe it will help

[ksco]

I've tried that, doesn't looks useful.

BOX64: ignoring prctl(PR_SET_SECCOMP, ...)
Last calls
1571|0x104ad3bfb: Calling __pthread_mutex_unlock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D748, 0xB, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3d1b: Calling pthread_mutex_lock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D8D8, 0x3A, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3d3e: Calling __pthread_mutex_unlock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D8D8, 0x3A, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3d81: Calling pthread_mutex_lock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D928, 0xC44, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3da4: Calling __pthread_mutex_unlock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D928, 0xC44, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3eeb: Calling pthread_mutex_lock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D9C8, 0x50E, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3f10: Calling __pthread_mutex_unlock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D9C8, 0x50E, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3f57: Calling pthread_mutex_lock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0DA18, 0x100, 0xFFFFFFF7, ...) => return 0x0
1571|0x104ad3f7c: Calling __pthread_mutex_unlock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0DA18, 0x100, 0xFFFFFFF7, ...) => return 0x0
1571|0x103790ced: Calling clock_gettime (/lib/riscv64-linux-gnu/libc.so.6)(0x1, 0x10B37CC60, 0xFFFFFFF7, ...) => return 0x0
1571|0x107c0e616: Calling clock_gettime (/lib/riscv64-linux-gnu/libc.so.6)(0x1, 0x10B37CC80, 0x44C6FF921E, ...) => return 0x0
1571|0x107c0e616: Calling clock_gettime (/lib/riscv64-linux-gnu/libc.so.6)(0x1, 0x10B37CD40, 0x60CBA, ...) => return 0x0
1571|0x104ac6f69: Calling __getpid (/lib/riscv64-linux-gnu/libc.so.6)(0x38A69530, 0x1, 0x0, ...) => return 0x623
1571|0x103790ced: Calling clock_gettime (/lib/riscv64-linux-gnu/libc.so.6)(0x1, 0x10B37C9F0, 0x0, ...) => return 0x0
1571|0x107c127d6: Calling my___vsnprintf_chk (code)(0x10B37C910, 0x100, 0x1, ...) => return 
1571|0x104ad3bd8: Calling pthread_mutex_lock (/lib/riscv64-linux-gnu/libc.so.6)(0x36A0D748, 0xB, 0xFFFFFFF7, ...) => return 0x0
1571|SIGSEGV @0x3ff103f072 (strlen (/lib/riscv64-linux-gnu/libc.so.6)) (x64pc=0x2f0b53/???:"???", rsp=0x10b37c818), for accessing (nil) (code=1)
RAX:0x000000010b37ca40 RCX:0xffffffffffffffff RDX:0x0000000000000001 RBX:0x0000000000000100 
RSP:0x000000010b37c818 RBP:0x000000010b37c830 RSI:0x0000000000000100 RDI:0x000000010b37c910 
 R8:0x00000001029569a3  R9:0x000000010b37c8f0 R10:0x0000000000000017 R11:0x5555555555555555 
R12:0x00000001026e5303 R13:0x0000000000000000 R14:0x000000010b37c910 R15:0x000000010b37c910 
Segmentation fault

[ptitSeb]

Well, the issue is in my___vsnprintf_chk(...)
Must be some wrong wrapping or something like that.

[ksco]

Hmm, I remember this function got some fixes just a few days ago, I thought it was fine..

[ksco]

Yes, it indeed segfaulted in my___vsnprintf_chk, might be something off in myStackAlignValist, I'll debug it later, thanks!

[ksco]

When calling my___vsnprintf_chk, the third vararg on the stack(overflow_arg_area[2]) is interpreted as a char * but has some garbage value 0x3ff0000000000000. Looks like it's not a problem with my___vsnprintf_chk, the problem comes before it.

[ptitSeb]

Thta looks like a float value. What is the fmt string?

[ksco]

It's

[%d:%p] %8.0f ms: %s%s%s %.1f (%.1f) -> %.1f (%.1f) MB, %.1f / %.1f ms %s (average mu = %.3f, current mu = %.3f) %s; %s

gp_offset is 16, fp_offset is 48.

[ksco]

Floating point values (9 of them out of 16 slots) are not touching the stack, there shouldn't be a float value on the stack.

[ksco]

Unless it is! I changed X64_VA_MAX_XMM from ((6*8)+(8*16)) to ((6*8)+(8*8)), and it works!!!! That's so unobvious!

[ksco]

I'm so happy that VS Code works! Yay!!!

[ksco]

It's amazing you can tell from the hex that this is a float...

[ksco]

So we should define X64_VA_MAX_XMM as ((6*8)+(8*16)) when CONVERT_VALIST is present, otherwise ((6*8)+(8*8)), right?

[ptitSeb]

Ah yes, size of an xmm reg is 16bytes! not 8

(yeah, I see float and double in hex dump... I spend too much time looking at hex dump !!!)

[ksco]

VS Code starts fine, but there is only a blank window, which seems an OpenGL issue (not sure). Weixin won't start for some reason, but it's gone much further. It's some progress nevertheless.

[ptitSeb]

Yes, it might be an opengl issue. Try withou/without gl4es (Electron should be compatible with GLES2, but I don't remember if I wrapped libGLESv2 :S))

[ksco]

With or w/o gl4es acts the same, with some GL errors printed in both ways.

[ksco]

I accidentally turned off Dynarec when compiling box64 yesterday, VS Code is still not working with RV64 Dynarec.

[ksco]

A lot of diffs on MOV r/m64, imm32 is reported by cosim, which is strange.

Warning, difference between Interpreter and Dynarec in 0x10552f94b (48 c7 47 08 ff ff ff 7f)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
MEM: @0x3fb430e8a0 : ff ff ff 7f 00 00 00 00 | ff ff ff 7f ff ff ff ff

[ptitSeb]

Looks like a sign extension issue here. But on the interpreter side?

Also, beware, not sure the address given as an error is the right one. It might be off by 1 opcode....

You need to check the generated code around the address to really understand what is going on.

[ksco]

It might be off by 1 opcode.

Oh? I didn't aware of that.

But on the interpreter side?

The interpreter is fine, so that got me confused. Anyway I'm trying to look at opcodes near it to see if something is off.

[ksco]

I'm struggling with debugging this, @ptitSeb can you try to fix it when you have the time?