Comments (25)
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?)
from box86.
opfor for linux crashes on last boss, so it is not very good idea. And there is native opfor port now
from box86.
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
from box86.
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
from box86.
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
from box86.
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
from box86.
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
from box86.
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.
from box86.
No, stdcall is cdecl with retn, separate wrappers not needed.
from box86.
I yes, I was mistaking it with fastcall
, sorry.
from box86.
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.
from box86.
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.
from box86.
Yes, i do not need syscall and GetGSBase for dll, so i am writing stubs now
from box86.
context->stack used in print_log calls from x86emu, is this correct? emulator may have different stack
from box86.
print_log(...)
doesn't use context->stack
, this is used only in emulator side, never on the ARM side.
from box86.
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?
from box86.
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
?
from box86.
I set context to NULL and got crash in internalX86Setup:
if(context->x86trace) {
After commenting-out it emulator runs if log disabled.
from box86.
yes I see. Basically, you just want an x86 emulator, and nothing else here.
from box86.
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)
from box86.
https://github.com/FWGS/dllemu/blob/master/box86stub.c
from box86.
from box86.
Is it running the original client dll ? or server ? or both ?
from box86.
Server only, wrapper for client is not done
from box86.
Nice!
from box86.
Related Issues (20)
- L4T Bionic Broken Elements When Navigating Steam Client
- Source Dedicated Server (TF2) fails to dlopen `engine_srv.so` due to `libc.so.6` HOT 3
- building on rk3588s HOT 11
- how install box 86 on orange pi (arch linux) ? HOT 7
- Cemu HOT 3
- box86:armhf on arm64 missing opcodes in Fallout Tactics and Diablo 2 HOT 3
- Steamwebhelper is not responding HOT 15
- Steam: Missing symbols HOT 10
- box86 steam You are missing the following 32-bit libraries, and Steam may not run: libc.so.6 HOT 10
- Support mali vulkan driver HOT 1
- Regression on Super Meat Boy my2_SDL_GL_GetProcAddress HOT 4
- Killing Floor Dedicated Server Crashes with SIGSEGV HOT 4
- Wheel of Time on RPi5/64
- Build Error on Raspberry Pi 5: _TIME_BITS=64 Requirement Conflict HOT 11
- Steam fail to start due to symbol err HOT 14
- Wrong ELF class on Switch HOT 1
- Question about ODROID target HOT 6
- Unhandled page fault on read access to FFFFFFFF at address 00000000 (thread 0024), starting debugger... HOT 1
- Box86 fails to run on Ubuntu 24.04 HOT 11
- Relocation type "0x2a" error running bash. Unable to run bash in nixOS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from box86.