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)
- Box86 fails to run on Ubuntu 24.04 HOT 11
- Relocation type "0x2a" error running bash. Unable to run bash in nixOS HOT 1
- SteamCMD Via Box86 On Termux Not Loading Steam API HOT 4
- how to solve "bash: No such file or directory"? HOT 2
- Steam installed via install_steam.sh script not working HOT 11
- SteamCMD fails with futex robust_list not initialized by pthreads HOT 6
- Feed and grow : fish dont open (rpi5) HOT 1
- Please dont hard code compiler paths HOT 9
- Problems with Vulkan with Wine HOT 2
- wine is broken HOT 11
- Wine cannot create window HOT 3
- RK3588, 6.1 Rockchip Kernel, Joshua Riek Ubuntu Desktop HOT 1
- Infinite checking update steam HOT 2
- Wine reported that the gnutls missing symbol when running counter-strike 1.6 HOT 1
- install_steam.sh on 24.04 & Raspberry Pi 5 HOT 5
- Infinite Loop on SteamCMD Checking for Update.
- [Question] Error occurred while installing steam on KylinOS showing __dprintf_chk not found HOT 16
- Segmentation fault while launching Valheim Server + BepinEX HOT 2
- Segmentation fault on Raspi 5
- Error when launching CSGO game
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.