Any API/library build? about box86

[ptitSeb]

Nice!
I have plan to be able to build box86 as a x86 lib wrapper. I wanted to have that for Opposing Force, but using linux lib.
So this is something limilar to what you are doing (you have gone further then what I have in mind it seems).
For that, my plan is to change CMakeList.txt to add a "build as lib" option, and have a (optionnaly) limited set of wrapped lib, and not having the launcher.

(also, bridge already support "retn", right?)

[mittorn]

opfor for linux crashes on last boss, so it is not very good idea. And there is native opfor port now

[mittorn]

Firstly, i added new wrapper generation code that hacks stack after stdcall (because i do not know x86 too much), but now i just using retn. There only change needed in emulator code is FS segment support. If you planning to make API, need an export for setting FS segment, it used for TLS and exception handling in msvcrt

[mittorn]

And i am using private api in game wrappers, which may need to access fpu return value and in initterm (msvcrt constructors) implementation which need to save registers state between calls

[mittorn]

Maybe also need add option to disable wrappers and elf loading at all because it is not cross-platform. I am planning to use it on musl and android, but there are non-linux systems which can run x86 emulator and dll loader too

[mittorn]

Uploaded dirty startup code to https://github.com/FWGS/dllemu
It is very WIP and gives many warnings, so need to be completely reworked. wrapper generator changes not needed, i only left it to upload existing code and move it to other PC

[mittorn]

Open-source opfor may be found here if still needed https://github.com/nillerusr/hlsdk-xash3d https://github.com/H-I-N-G/hlsdk-xash3d (opfor branch), but i do not remember which is actual

[ptitSeb]

Ah, ok, thanks for the opfor branch. I'll check that later.

For "stdcall" wrapper, I can probably try to implement that in the wrapper, but yeah, from memory, the first 3 or 4 args are in register, instead of everything on stack.

And yeah, FS: is not really handled for now. The whole segments are not really checked in box86, I'm just hardcoding stuff for now.

[mittorn]

No, stdcall is cdecl with retn, separate wrappers not needed.

[ptitSeb]

I yes, I was mistaking it with fastcall, sorry.

[mittorn]

Trying to minimize dependencies
I excluded all wrappers from build and got this undefined symbols:

/home/mittorn/xash3d-dllemu/dllemu/box86/src/emu/x86syscall.c:468: undefined reference to `my_getrandom'
/tmp/ccoo5u4p.o: In function `my_syscall':
/home/mittorn/xash3d-dllemu/dllemu/box86/src/emu/x86syscall.c:513: undefined reference to `my_open'
/tmp/ccymngrR.o: In function `io_convert':
/home/mittorn/xash3d-dllemu/dllemu/box86/src/wrapped/generated/wrapper.c:28: undefined reference to `my__IO_2_1_stderr_'
/home/mittorn/xash3d-dllemu/dllemu/box86/src/wrapped/generated/wrapper.c:30: undefined reference to `my__IO_2_1_stdin_'
/home/mittorn/xash3d-dllemu/dllemu/box86/src/wrapped/generated/wrapper.c:32: undefined reference to `my__IO_2_1_stdout_'

Maybe it need to be moved to tools or librtools

Also, only need this from elfloader:

/home/mittorn/xash3d-dllemu/dllemu/box86/src/emu/x86run_private.c:59: undefined reference to `GetNameOffset'
/tmp/ccPVidaX.o: In function `GetGSBaseEmu':
/home/mittorn/xash3d-dllemu/dllemu/box86/src/emu/x86run_private.c:603: undefined reference to `GetGSBase'

So elfloader may be easily disabled too for targets which not need it
and some globals like box86_log, ftrace in main binary. But i not tried to enable dynarec, maybe there are more dependencies.

[ptitSeb]

If you exclude wrapper, you probably don't need x86syscall neither?
But yeah, I could move those function else were from wrappedlibc to some place more conveniant.

GetGSBase use many elfloader stuff... so I your case, if you don't need TLS data, it would probably be better to write a stub, that just return stuff like canary but not all TLS stuffs.

[mittorn]

Yes, i do not need syscall and GetGSBase for dll, so i am writing stubs now

[mittorn]

context->stack used in print_log calls from x86emu, is this correct? emulator may have different stack

[ptitSeb]

print_log(...) doesn't use context->stack, this is used only in emulator side, never on the ARM side.

[mittorn]

box86/src/emu/x86run_private.c:59:    const char *ret = GetNameOffset(emu->context->maplib, p);
box86/src/emu/x86run_private.c:603:    return (uintptr_t)GetGSBase(emu->context);
box86/src/emu/x86run_private.c:616:        pthread_mutex_lock(&emu->context->mutex_trace);
box86/src/emu/x86run_private.c:619:        if((emu->context->trace_tid != tid) || (emu->context->trace_dynarec!=dynarec)) {
box86/src/emu/x86run_private.c:621:            emu->context->trace_tid = tid;
box86/src/emu/x86run_private.c:622:            emu->context->trace_dynarec = dynarec;
box86/src/emu/x86run_private.c:625:        if(emu->context->trace_tid != tid) {
box86/src/emu/x86run_private.c:627:            emu->context->trace_tid = tid;
box86/src/emu/x86run_private.c:648:        pthread_mutex_unlock(&emu->context->mutex_trace);
box86/src/emu/x86int3.c:29:    for (int i=emu->context->atfork_sz-1; i>=0; --i)
box86/src/emu/x86int3.c:30:        EmuCall(emu, emu->context->atforks[i].prepare);
box86/src/emu/x86int3.c:42:        for (int i=0; i<emu->context->atfork_sz; --i)
box86/src/emu/x86int3.c:43:            EmuCall(emu, emu->context->atforks[i].parent);
box86/src/emu/x86int3.c:47:        for (int i=0; i<emu->context->atfork_sz; --i)
box86/src/emu/x86int3.c:48:            EmuCall(emu, emu->context->atforks[i].child);
box86/src/emu/x86int3.c:68:            if(box86_log>=LOG_DEBUG /*&& emu->trace_end==0 && !emu->context->x86trace*/) {
box86/src/emu/x86int3.c:69:                pthread_mutex_lock(&emu->context->mutex_trace);
box86/src/emu/x86int3.c:177:                pthread_mutex_unlock(&emu->context->mutex_trace);
box86/src/emu/x86int3.c:179:                pthread_mutex_lock(&emu->context->mutex_trace);
box86/src/emu/x86int3.c:206:                pthread_mutex_unlock(&emu->context->mutex_trace);
box86/src/emu/x86run.c:51:    printf_log(LOG_DEBUG, "Run X86 (%p), EIP=%p, Stack=%p\n", emu, (void*)R_EIP, emu->context->stack);
box86/src/emu/x86run.c:607:            pthread_mutex_lock(&emu->context->mutex_lock); // XCHG always LOCK
box86/src/emu/x86run.c:611:            pthread_mutex_unlock(&emu->context->mutex_lock);
box86/src/emu/x86run.c:616:            pthread_mutex_lock(&emu->context->mutex_lock); // XCHG always LOCK
box86/src/emu/x86run.c:620:            pthread_mutex_unlock(&emu->context->mutex_lock);

i tried comment-out tracing and disable logging and it even runs with NULL context
but my question about this:

box86/src/emu/x86run.c:51:    printf_log(LOG_DEBUG, "Run X86 (%p), EIP=%p, Stack=%p\n", emu, (void*)R_EIP, emu->context->stack);

calling Run on emu, but it prints stack address from emu->context. Is this correct?

[ptitSeb]

calling Run on emu, but it prints stack address from emu->context. Is this correct?

Yes it is. Are you trying to remove print_log(...) or emu->stack ?

[mittorn]

I set context to NULL and got crash in internalX86Setup:
if(context->x86trace) {
After commenting-out it emulator runs if log disabled.

[ptitSeb]

yes I see. Basically, you just want an x86 emulator, and nothing else here.

[mittorn]

emulator (and maybe dynarec), bridge, some helper functions like myalign because it needed for variadics, maybe callback (but i not using it now, just replaced by stubs, but need it later)

[mittorn]

https://github.com/FWGS/dllemu/blob/master/box86stub.c

[mittorn]

https://expired.mentality.rip/media/bf1df52a36bda854c8a81f9f609c7c19d78ff45cb08e3b7b42b2ba1b3e697e02.png

[ptitSeb]

Is it running the original client dll ? or server ? or both ?

[mittorn]

Server only, wrapper for client is not done

[ptitSeb]

Nice!