(Feature Request) Something like FEXBash but for box64

[AMDBartek]

This is not an issue but rather a feature request, FEX has something called FEXBash which allows you to run a bash shell where you can use arm64 and x86_64 software at the same time. I noticed that there is a bash x86_64 binary in the tests folder however you cannot run other x86_64 binaries using it.

root@localhost:~/box64-dynarec-debugging# ./box64-dynarec-debugging
execve("./box64-dynarec-debugging", 0x65e845f0, 0x65ce5fa0) is x64=0 x86=0 (my_context->envv=0x7874533e28, environ=0x7fe3e4e110
bash: ./box64-dynarec-debugging: No such file or directory
root@localhost:~/box64-dynarec-debugging#

This would be a nice feature to have as you can run bash scripts that use x86_64 binaries on systems which do not use binfmt.

[ptitSeb]

the bash include should be usable. I don't understand this log. What is bix86-dynamic-debugging? Is it an Aarch64 binary? because it's not recognised as a x86 or x86_64 binary it seems.

[AMDBartek]

Apologies, that was a bit unclear. The binary I used is the one I made for issue #361. It is a valid x86_64 binary (works somewhat on box64 with box64 ./box64-dynarec-debugging or on an x86_64 system).

Termux does not have binfmt support, could a simple wrapper or something be made that allows you to run a bash shell that works with x86_64 binaries without binfmt?

[ptitSeb]

well, I guess I need to do some test on my side, but it's strange the binary is not recognise as x64. maybe there is an issue with the current folder?

[ptitSeb]

I did some tests localy, and it does works fine for me. I do get x86_64 and aarch64 (and scripts) launching fine. Also uname -m shows x86_64 instead of aarch64 :) (uname -a shows the native full string, with aarch64 tho)

[AMDBartek]

uname -m also works perfectly for me and says x86_64. aarch64 executables also run in the x86_64 bash but running x86_64 executables does not work and gives the usual no such file or directory error.

Even though I am calling an x86_64 executable from x86_64 bash would I need binfmt? Because Termux does not support it as for binfmt to work the system needs to use systemd which android does not.

[ptitSeb]

It should not need binfmt, because it is supposed to detect the file is an x86 or x86_64 and use box86 / box64 respectively. But in your log, the file was not recognised as an x86_64 binary, so it was launching execve without box64. I tried on my side running test/test01 and it just worked (and was detected as x64)

[ptitSeb]

pi@odroidn2p:~/box64/build$ box64 ../tests/bash
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL PageSize:4096
Box64 with trace with Dynarec v0.1.9 5f6104a built on Aug 30 2022 10:17:11
Using default BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/
Using default BOX64_PATH: ./:bin/
Counted 35 Env var
Looking for ../tests/bash
Rename process to "bash"
Using native(wrapped) libtinfo.so.6
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
bash: eval: line 31: syntax error near unexpected token `"/usr/bin/lesspipe",'
bash: eval: line 31: `execve("/usr/bin/lesspipe", 0x854d7990, 0x854b7af0) is x64=0 x86=0 (my_context->envv=0xffffba5c0360, environ=0xffffff98b870'
bash: eval: line 77: syntax error near unexpected token `"/usr/bin/dircolors",'
bash: eval: line 77: `execve("/usr/bin/dircolors", 0x854efb50, 0x854c5d00) is x64=0 x86=0 (my_context->envv=0xffffba5c0360, environ=0xffffff98b870'
pi@odroidn2p:~/box64/build$ uname -a
execve("/usr/bin/uname", 0x8572e260, 0x854b7af0) is x64=0 x86=0 (my_context->envv=0xffffba5c0360, environ=0xffffff98b870
Linux odroidn2p 5.17.5-meson64 #22.05.1 SMP PREEMPT Sat May 28 08:20:29 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
pi@odroidn2p:~/box64/build$ uname -m
execve("/usr/bin/uname", 0x857438b0, 0x854b7af0) is x64=0 x86=0 (my_context->envv=0xffffba5c0360, environ=0xffffff98b870
x86_64
pi@odroidn2p:~/box64/build$ ../tests/test01
execve("../tests/test01", 0x8575e010, 0x854b7af0) is x64=1 x86=0 (my_context->envv=0xffffba5c0360, environ=0xffffff98b870
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL PageSize:4096
Box64 with trace with Dynarec v0.1.9 5f6104a built on Aug 30 2022 10:17:11
BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/
BOX64_PATH: ./:bin/
Counted 35 Env var
Looking for ../tests/test01
Rename process to "test01"
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
Hello x86_64 World!
pi@odroidn2p:~/box64/build$ exit
exit
pi@odroidn2p:~/box64/build$

Here is a short session (but yes, this system as binfmt), the important thing is the "is x64=1" in the execve log, so box64 is inserted in the call.

[ptitSeb]

And here is a short session done on my Pandora, using box86 only (it's a 32bits only cpu), without binfmt:

/media/sda1/sources/git/box86/build$ box86 ../tests/bash
Box86 with trace with Dynarec v0.2.7 4946642f built on Aug 30 2022 10:32:16
/media/sda1/sources/git/box86/build$ uname -m
i686
/media/sda1/sources/git/box86/build$ uname -a
Linux gigaseb 3.2.102 #1324 Sun Jun 24 19:08:21 EEST 2018 armv7l GNU/Linux
/media/sda1/sources/git/box86/build$ ../tests/test01
Box86 with trace with Dynarec v0.2.7 4946642f built on Aug 30 2022 10:32:16
Hello World!
/media/sda1/sources/git/box86/build$ echo ${BASH_VERSION}
5.1.16(1)-release
/media/sda1/sources/git/box86/build$

[AMDBartek]

Not sure then, do you have any idea what it could be? The source code and binary are available to download from the issue https://github.com/ptitSeb/box64/issues/361#issuecomment-1212222605 if you think it is an issue with the binary.

EDIT: Yeah I think it may be something with the binary? test01 works. The dynarec debugging binary does launch when I use box64 box64-dynarec-debugging though.

[ptitSeb]

works for me:

pi@odroidn2p:~/box64/build$ box64 ../tests/bash
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL PageSize:4096
Box64 with trace with Dynarec v0.1.9 5f6104a built on Aug 30 2022 10:17:11
Using default BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/
Using default BOX64_PATH: ./:bin/
Counted 35 Env var
Looking for ../tests/bash
Rename process to "bash"
Using native(wrapped) libtinfo.so.6
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
bash: eval: line 31: syntax error near unexpected token `"/usr/bin/lesspipe",'
bash: eval: line 31: `execve("/usr/bin/lesspipe", 0x824a79c0, 0x82487b20) is x64=0 x86=0 (my_context->envv=0xffffb4e9b360, environ=0xfffffa5a3990'
bash: eval: line 77: syntax error near unexpected token `"/usr/bin/dircolors",'
bash: eval: line 77: `execve("/usr/bin/dircolors", 0x824bfb80, 0x82495d30) is x64=0 x86=0 (my_context->envv=0xffffb4e9b360, environ=0xfffffa5a3990'
pi@odroidn2p:~/box64/build$ cd box64-dynarec-debugging/
pi@odroidn2p:~/box64/build/box64-dynarec-debugging$ ls
execve("/usr/bin/ls", 0x8276d530, 0x82487b20) is x64=0 x86=0 (my_context->envv=0xffffb4e9b360, environ=0xfffffa5a3990
box64-dynarec-debugging  src
pi@odroidn2p:~/box64/build/box64-dynarec-debugging$ ./box64-dynarec-debugging
execve("./box64-dynarec-debugging", 0x82787a40, 0x82487b20) is x64=0 x86=0 (my_context->envv=0xffffb4e9b360, environ=0xfffffa5a3990
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL PageSize:4096
Box64 with trace with Dynarec v0.1.9 5f6104a built on Aug 30 2022 10:17:11
BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/
BOX64_PATH: ./:bin/
Counted 35 Env var
Looking for ./box64-dynarec-debugging
Rename process to "box64-dynarec-debugging"
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
Using emulated /lib/x86_64-linux-gnu/libstdc++.so.6
Using native(wrapped) libm.so.6
Using emulated /lib/x86_64-linux-gnu/libgcc_s.so.1
Warning, CALL to 0x0 at 0x16de043 (0x16de042)
Hello, world!
pi@odroidn2p:~/box64/build/box64-dynarec-debugging$ exit
exit

Oh, ok, so x64=0, so the binary is not detected directly, and yet, it runs using binfmt? I'll investigate.

[AMDBartek]

Not sure then (you are using an older version of the binary but that doesn't seem to be the issue), is there any logs I could provide that might help? It seems this is an issue in my end, I also made sure I am in the correct directory and everything

[AMDBartek]

My log (using bash from tests folder):

root@localhost:~/box64-dynarec-debugging# chmod +x box64-dynarec-debugging
execve("/bin/chmod", 0x65e7dbf0, 0x65ceaef0) is x64=0 x86=0 (my_context->envv=0x75398a3e18, environ=0x7fc69e1dc0      root@localhost:~/box64-dynarec-debugging# ./box64-dynarec-debugging
execve("./box64-dynarec-debugging", 0x65e847c0, 0x65ceaef0) is x64=0 x86=0 (my_context->envv=0x75398a3e18, environ=0x7fc69e1dc0
bash: ./box64-dynarec-debugging: No such file or directory
root@localhost:~/box64-dynarec-debugging#

[ptitSeb]

Yeah, I guess the signature analysis part is wrong, as it doesn't detect an x64 in execve, but does load fine with elfloader. I have everything I need to fix this now, don't worry.

[ptitSeb]

Ok, should be fixed now :)

[AMDBartek]

Yep! It works, thank you very much.