Closed ETeissonniere closed 8 years ago
yes, the backend for ARM is not available yet. this is still in my plan.
at the moment, even though Unicorn can emulate multiple architectures, it only works for X86 host.
i have no ARM hardware at the moment. if you can donate a Raspberry Pi, i can put this as priority! a Chromebook is also welcome :-)
thanks.
Please explain how I can help you, maybe having qemu for arm... Le 21 oct. 2015 11:41, "Nguyen Anh Quynh" notifications@github.com a écrit :
yes, the backend for ARM is not available yet. this is still in my plan.
at the moment, even though Unicorn can emulate multiple architectures, it only works for X86 host.
i have no ARM hardware at the moment. if you can donate a Raspberry Pi, i can put this as priority! a Chromebook is also welcome :-)
thanks.
— Reply to this email directly or view it on GitHub https://github.com/unicorn-engine/unicorn/issues/209#issuecomment-149838693 .
On Odroid C1 it looks like this:
CC arm-softmmu/cpu-exec.o
In file included from /home/odroid/temp/unicorn/qemu/tcg/tcg-op.h:24:0,
from /home/odroid/temp/unicorn/qemu/tcg/tcg.c:49:
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c: In function ‘tcg_target_init_x86_64’:
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c:1997:22: error: ‘tcg_target_available_regs’ undeclared (first use in this function)
tcg_regset_set32(tcg_target_available_regs[TCG_TYPE_I32], 0, 0xffff);
^
/home/odroid/temp/unicorn/qemu/tcg/tcg.h:140:42: note: in definition of macro ‘tcg_regset_set32’
#define tcg_regset_set32(d, reg, val32) (d) |= (val32) << (reg)
^
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c:1997:22: note: each undeclared identifier is reported only once for each function it appears in
tcg_regset_set32(tcg_target_available_regs[TCG_TYPE_I32], 0, 0xffff);
^
/home/odroid/temp/unicorn/qemu/tcg/tcg.h:140:42: note: in definition of macro ‘tcg_regset_set32’
#define tcg_regset_set32(d, reg, val32) (d) |= (val32) << (reg)
^
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c:1998:22: error: ‘tcg_target_call_clobber_regs’ undeclared (first use in this function)
tcg_regset_set32(tcg_target_call_clobber_regs, 0,
^
/home/odroid/temp/unicorn/qemu/tcg/tcg.h:140:42: note: in definition of macro ‘tcg_regset_set32’
#define tcg_regset_set32(d, reg, val32) (d) |= (val32) << (reg)
^
In file included from /home/odroid/temp/unicorn/qemu/tcg/tcg.c:259:0:
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c:2011:32: warning: passing argument 1 of ‘tcg_add_target_add_op_defs_x86_64’ from incompatible pointer type
tcg_add_target_add_op_defs(arm_op_defs);
^
In file included from <command-line>:0:0:
/home/odroid/temp/unicorn/qemu/x86_64.h:2815:36: note: expected ‘struct TCGContext *’ but argument is of type ‘const struct TCGTargetOpDef *’
#define tcg_add_target_add_op_defs tcg_add_target_add_op_defs_x86_64
^
/home/odroid/temp/unicorn/qemu/tcg/tcg.h:783:6: note: in expansion of macro ‘tcg_add_target_add_op_defs’
void tcg_add_target_add_op_defs(TCGContext *s, const TCGTargetOpDef *tdefs);
^
/home/odroid/temp/unicorn/qemu/x86_64.h:2815:36: error: too few arguments to function ‘tcg_add_target_add_op_defs_x86_64’
#define tcg_add_target_add_op_defs tcg_add_target_add_op_defs_x86_64
^
/home/odroid/temp/unicorn/qemu/tcg/arm/tcg-target.c:2011:5: note: in expansion of macro ‘tcg_add_target_add_op_defs’
tcg_add_target_add_op_defs(arm_op_defs);
^
/home/odroid/temp/unicorn/qemu/x86_64.h:2815:36: note: declared here
#define tcg_add_target_add_op_defs tcg_add_target_add_op_defs_x86_64
^
/home/odroid/temp/unicorn/qemu/tcg/tcg.h:783:6: note: in expansion of macro ‘tcg_add_target_add_op_defs’
void tcg_add_target_add_op_defs(TCGContext *s, const TCGTargetOpDef *tdefs);
^
CC aarch64-softmmu/translate-all.o
CC aarch64-softmmu/cpu-exec.o
CC arm-softmmu/tcg/tcg.o
CC aarch64-softmmu/tcg/tcg.o
CC aarch64-softmmu/tcg/optimize.o
make[2]: *** [tcg/tcg.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [subdir-x86_64-softmmu] Error 2
make[1]: *** Waiting for unfinished jobs....
yes, it is the same issue.
Why don't you set up a donation button on the unicorn home page towards this goal? If an arm SBC is needed, the $35 or so should be rather easy to raise.
i will think about that. to clarify: it is not like i cannot afford such a machine, but it is more about getting community involved & contributed for this open source project.
thanks.
Indeed, that's precisely what I had in mind :)
BTW, could you or lunixbochs comment on the suitability of both your projects in this thread?
yes, building emulators for games on top of Unicorn should be one of the most prominent applications of this engine. a lot of hard work is needed, but i really look forward to the first game emulator like this.
so the idea is that you have x86 binary, and you want to emulate that on ARM?
Yep, that's what the person was asking about. It would be great in an x86 linux SDL game if the SDL/OpenGL parts could get translated natively using the local SDL and glshim.
I think if you care to post there yourself, maybe the odroid guys could help with some hardware needs. It should be good for the project's publicity anyway. (a separate thread would be a good idea, especially right above ExaGear :) )
glshim can already punch through a user-mode emulator for rendering, without the emulator's participation, as long as shared memory is supported (which unfortunately does not currently include Unicorn/Usercorn, as there's no file mmap interface, but I just opened #261 for that). Check out https://boards.openpandora.org/topic/11506-glshim/?page=17#comment-393842 for some info on using it with Exagear.
Unfortunately QEMU's CPU perf won't come close to Exagear's for games without some floating point changes (which I've PoC'd for a ~2x speedup, though full NEON support in TCG would be better), and maybe a single address map mode where guest = host address (that's part of why Exagear has such fast memory IO).
I'm actually pretty interested in writing a runtime-assisted static recompiler with Usercorn to assist with porting games as well.
Thanks, strange that the ExaGear announcement from a few days ago doesn't mention this at all. Even if still unofficial and unsupported it looks like the best bet. (at least until a Unicorn based emulator becomes usable)
They know about it and I've been working with them on it, but I guess they're waiting for better WINE support.
@aquynh, would you be willing to give an overview of the work that would be required to write a backend for ARM hosts?
you can diff Unicorn's qemu/tcg/i386/* with the same directory of Qemu 2.2.1 to see what was changed for Unicorn. then you do similar thing with qemu/tcg/arm/.
@gaffe23 it almost compiles. TCG has slightly different backends for each arch. Take a look at my comment here https://github.com/unicorn-engine/unicorn/pull/259
TCG needs to be tweaked slightly from normal QEMU, because on normal QEMU you have a different QEMU binary for each architecture (like qemu-i386, qemu-arm, etc). With Unicorn, qemu-i386 and qemu-arm are both in the same binary, which I think causes tcg.o to link multiple times. tcg.o for ARM currently throws "duplicate variable definition" if you link it multiple times due to some extern-defined ARM platform detection variables.
i dont have time right now, but you can take a look at qemu/header_gen.py. some duplication symbols can be put there, and then you run "make header" to generate new code. this helps in some cases, but sometimes you need to modify more in the core to solve this duplication problem.
@lunixbochs, you should diff qemu/tcg/i386/* against Qemu 2.2.1 to see what else is modified for Unicorn. it is a bit more complicated than just fixing some duplication symbols.
@aquynh Have you seen the recent $5 Rpi Zero news? I could donate that much to be able to play with usercorn on arm :)
Haha is this still possible to run Ubuntu with Gcc on this machine? if so, would be a nice platform to test.
Yes will be great if you can donate. Can you please email me for more discussion? Thanks!
Running in cli mode won't be a problem, it's an ordinary single-core 512 MB Rpi, slightly overclocked - the only problem I foresee is being able to get it quickly (it's already sold out at the moment I think). You'd still have to pay shipping :)
Hopefully the issue is trivial and it will soon become possible to try x86 emulation out:
EDIT: Yes indeed, it's already working for me.
Good job ! Hope i will be able to contribute, let's dive in the code ! Le 18 janv. 2016 10:52, "petevine" notifications@github.com a écrit :
Hopefully the issue is trivial and it will soon become possible to try x86 emulation out:
382 https://github.com/unicorn-engine/unicorn/issues/382
— Reply to this email directly or view it on GitHub https://github.com/unicorn-engine/unicorn/issues/209#issuecomment-172481683 .
cool! you guys are still welcome to donate some hardware so i can play with this :-)
Anyone wanting to build unicorn natively, be aware the Makefile defaults to:
make -j8
so on 1GB boards it's necessary to provide some (ZRAM) swap. Even so I was able to build entirely from ramdisk.
if we change that to "make -j4" by default, does it help?
Yeah, that will potentially halve the memory usage during build. I've also had issues building unicorn in virtual machines with limited ram.
i pushed a commit to change "-j8" to "-j4" by default
@aquynh I've put in a word for you in the thread about the upcoming 64-bit Odroid C2 board. I sincerely hope these guys possess some marketing savvy!
thanks for the word! Unicorn can compile and run on ARM64 now. please spread this news, thanks.
Hello guys, So, I have discovered your project because someone suggested it to me on freenode.net. I downloaded the code and do what COMPILE.txt explain, but I fail to compile using ./make.sh with the folowing error :
Hope it will be usefull and you can help me. Have a good day :smile:.