Segmentation Fault in amd64 executables

[herrhotzenplotz]

In the Linuxulator I see:

[nico@triton ~/src/bm]$ uname -ap
FreeBSD triton.herrhotzenplotz.geek 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #2 main-c111-g6eebda3bb: Thu Jan 14 21:17:40 CET 2021     nico@triton.herrhotzenplotz.geek:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 amd64
[nico@triton ~/src/bm]$ 
[nico@triton ~/src/bm]$ ./build-x86_64.sh  
...
[nico@triton ~/src/bm]$ brandelf -t Linux ./build/examples/fib.exe
[nico@triton ~/src/bm]$ ./build/examples/fib.exe
[5] + Segmentation fault - core dumped ./build/examples/fib.exe
[nico@triton ~/src/bm]$ file ./build/examples/fib.exe
./build/examples/fib.exe: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, with debug_info, not stripped
[nico@triton ~/src/bm]$ gdb ./build/examples/fib.exe fib.exe.core 
Reading symbols from ./build/examples/fib.exe...

warning: core file may not match specified executable file.
[New LWP 100639]
Core was generated by `./build/examples/fib.exe'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000020177c in inst_49 ()
(gdb) where
#0  0x000000000020177c in inst_49 ()
#1  0x0000000000000001 in ?? ()
#2  0x00007fffffffd7d0 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) x/i $pc
=> 0x20177c <inst_49+8>:    movq   $0xa,(%rsi)
(gdb) p/x $rsi
$1 = 0x2a2000
(gdb) 

Same applies to 123i.exe.
No idea whether that is expected or not. If you need the corefile or the gdb trace of 123i.exe for debugging purposes, please let me know :-)

[rexim]

@herrhotzenplotz sorry for bothering you in such an old issue. This was due to not all instructions being implemented. Recently we got all of them implemented #344 and I was wondering is this still an issue?

[herrhotzenplotz]

This was due to not all instructions being implemented. Recently we
got all of them implemented #344 and I was wondering is this still
an issue?

I've tested this against a few test cases and cannot observe any
segmentation faults anymore.

However, none of the examples print anything to stdout/stderr. I will
dig into this a bit when I have a bit time for it, although I can
already feel, that it's just a matter of the syscall ID's being
assumed to be Linux.

See: https://paste.debian.net/plainh/bf52509e

Maybe this is worth another issue?

[herrhotzenplotz]

Quick note, yes, that is indeed the issue:

[nico@hades ~/src/bm]$  brandelf -t Linux /tmp/hello
[nico@hades ~/src/bm]$ /tmp/hello                   
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World
[nico@hades ~/src/bm]$ 

[rexim]

@herrhotzenplotz Thank you so much for checking it out!

I don't think it makes sense to create a separate issue for that, but PRs that add support for a new code generation target are welcome.

I renamed the target nasm to nasm-linux-x86-64 #367 to emphasize that it only works on Linux x86-64. Any PRs that add nasm-freebsd-x86-64 target are welcome ;)