Possible incorrect libc/libstdc++ initialization

[ValdikSS]

I'm running box86 commit ee0c949 (v0.3.8 basically)

Proprietary epson-inkjet-printer-201310w fails to produce correct output result: it produces much smaller file than with qemu-i386, with success exit code.
There are debug strings in the library which are called to no-op debug printf. I've re-activated this function to print to stderr, but with box86, this path is not activated and it does not print debug strings (the function is not called, if you put garbage code in there, it won't crash in box86).

Qemu successfully prints these debug lines into stderr, and produces correct file.

Don't have much time to investigate further right now, but it might be something with the library initialization step.
All I could say it it 'does not work'.

I'm running box86 on Debian 12, without x86lib files (Debian's libstdc++).
Disabling JIT does not help.

The files and the readme is in the archive.
box86-issue.zip

[ValdikSS]

box64-32 produces correct result, but still doesn't print any debug information in stderr (or stdout).

[ValdikSS]

I think *printf / *scanf are to blame, and I think this needs to be backported: ptitSeb/box64@21c86f9

[ValdikSS]

That did not work.

[ptitSeb]

Mmmm, so, I need to backport some fixes from box64 to box86?

But that still don't fix everything right?

[ValdikSS]

box86:

• Does not produce correct output file
• Does not print debug information to stderr

box64-32:

• Does not print debug information to stderr

Don't know the reason for either of the issues.
How can I debug that? Is there any way other than collecting a trace in a text file? Attaching a gdb maybe?

[ptitSeb]

Could it be that the output is 16bits instead of 8bits, and because Box64 (and Box86) print stuffs before the program, stdout/stderr switch to utf-8 and then will ignore utf-16 (there is an issue like that with unrar). Try using BOX64_NOBANNER=1 BOX64_LOG=0 for box32 (or simply ̀BOX86_NOBANNER=1` for box86, as log=0 is already default) to see if it improve things.

[ValdikSS]

I always run it with these options. The debug function seems to just not getting executed, the execution flow is different for some reason, but since it's a proprietary application and it works on native i386 and under qemu-i386, I don't know how to debug it under box86.
If it was regular execution, I'd end up with manual tracing with gdb. But here I don't know how to do that other than patching the code to UD2 to make it crash in several places, one step at a time.

[ptitSeb]

Well, you can gdb it too, because of the generated code, it's harder to follow the execution...

If you have a patch for box86 already, feel free to create a PR (else I'll try to it later today).

For debugging, you have 3 options (for both box86 & box64):

1. BOX86_LOG=2 will show all the wrapped function calls. Box64 trace might be slightly more detailled. You can use also BOX64_TRACE_FILE to redirect trace to a file for easier analysis (note that box64 default output is stderr, while box86 is stdout).
2. BOX86_DYNAREC_DUMP=2 to dump all the x86->arm conversion (box64 output has more meta data but should be equivalent). It's better to use a trace enabled version of box86/box64, coupled with BOX86_TRACE=0-1 to have proper x86 instruction decoded. TRACE enabled build will need libZydis.so. Box86 will need v3.x to work preperly. box64 can work with both v3.x or newer v4.x often distributed as OS packages.
3. BOX86_TRACE=1 or BOX86_TRACE=0x11111-0x222222 for a range or even BOX86_TRACE=my_function if debug information are present. You need a TRACE enabled build with libZydis available for this. This will generate a very big "dump", tracing each x86 opcode execution. You can also use BOX86_TRACE_START=NNNNN to strat trace only after NNNNN opcodes, and ̀BOX86_TRACE_INIT=1 to also enable trace during init of elfs. You might also need BOX86_DYNAREC_TRACE=1 or disable dynarec with BOX86_DYNAREC=0 to have trace on dynarec code...

If you can, prefer box64-32 there, as it might have more refined debugging capabilities (for example, there is BOX64_TRACE_COLOR=1 to have register that change in color, box86 doesn't have that).

That how I debug (and sometime, I just gdb --args box64 ./myprogram...

[ValdikSS]

Created a simple program which dlopens the library and calls the functions, all the prints are there.
Will try to debug some time in the future.