-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x86_64/aarch64, help making this work with https://gitlab.com/android_translation_layer/android_translation_layer? #2
Comments
As you can see, the project has been stalled since May 2020. I don't know how to write code, but I have been interested in Android native bridge. I hope this information is helpful to you and this project. At present, there is a native bridge implementation called berberis on the Android mainline source code, which is actually a riscv version of the closed source ndk_translation developed by Google for ARM to x86 (located in frameworks/libs/binary_translation). I suggest that you can refer to Berberis and native_bridge_support to refactor or improve this project. Moreover, QEMU can also achieve translation between other architectures, and this project will be very helpful. |
I'm looking forward to using this with waydroid. I can code in C/C++(just can), however I haven't any experience in the Android world. |
well, I added aarch64 support and made this work with ATL: https://gitlab.com/android_translation_layer/qemu-based-native-bridge/nb-qemu fwiw, for waydroid, which runs a full AOSP system, there are no practical downsides to using the proprietary libhoudini, so I doubt they really care all that much, unless someone else does all the work for them to bring this to feature parity I tested native tunnel (ndk example) and smashhit v1.4.3 and they run at 60 fps with occasional drops |
Oh you've gone further. Is the guest/bionic part build on aosp-q? I will try it. And I've come up with some new ideas. Build qemu-static separately, add binder/ashmem support to qemu. Then I think I can let the bridge run guest-support-program with qemu-static by exec() in the subprocess, then use some IPC implementation (like unix domain socket, shm or binder) to interact with the guest-program in qemu. This bridge implementation could easily switch the qemu-static to houdini-static or etc.. It also allows qemu to be built independently of bridge. But the efficiency of IPC may slow down the trampoline/thunk conversion. Currently I have few time and try to patch on new qemu. But I think once the two solutions are both ready then I could test the benchmark between them :) |
I don't think that makes much sense, we need non-upstreamable patches to qemu anyway. Houdini is also in-process afaik, and it's closed source so you can't exactly make it not be. And there's no way it wouldn't be slower, it would also make thunking pointers more annoying. Also, binder/ashmem are not a thing with ATL so I'm certainly not interested in maintaining that. The guest part is cross-compiled with no outside dependencies, so it should work as-is on android. It probably doesn't even matter what the host android version is. |
Yes I am aware of the issues. But I have been tried the original nb-qemu build, patching libffi as instructed. the result is that it doesn't work in the android emulator, maybe I'm missing something. And the qemu-arm binfmt_misc function is broken. cant find way to fix the problem that causes Android to freeze when starting up. The original qemu's Android makefile and the dependencies on capstone, glib, etc. are very annoying in Android builds. And my goal is not to run on ATL, but the current Android platform. So in my design I don't care about performance, I just want to be able to minimally modify qemu so that I don't have to port it to the Android build system. Because the original qemu-static can be used directly as a binfmt_misc in Android without patch. Just changing the linker path or LD_PREFIX, qemu can run ndk's ELF smoothly. So it would be possible for me to simply just have the bridge execute a designed guest program with qemu-static, communicating via local socket IPC and wrapping the thunk with libffi & IPC. Houdini-static (exist in houdini 12 and below, no static programs above houdini 13) fully supports all ioctl for android bionic, including binder/ashmem IPC. therefore, the thunk performance of bridge can be improved with the help of better IPC design. And since the translator runs in a subprocess, Houdini or even other linux translators (preferably static) such as box64 have the opportunity to run the guest program instead of qemu, and provide performance comparisons. This will help in improving and debugging other translators and also compare various issues during the runtime of the guest program. BTW I will try your nb-qemu (not very soon) to see if it runs on android since I do want to know its performance in nativebridge. |
it seems that termux was able to compile qemu for android: https://github.com/termux/termux-packages/tree/e358cd8718dd9ef9d7f1194535cf86cc20f0eb9e/packages/qemu-system-x86-64-headless Termux compiles everything natively against bionic, so it should work properly in-process. You could also use their glib/capstone etc I imagine. It seems they are using a newer version of Qemu, if you decide to forward port the patches I would be very grateful if you didn't break ATL support (which I guess shouldn't be that hard, all I did to make that work properly was remove Alternatively could probably go through the git history, seems they had that package for quite a while |
I suppose you could try to use termux's build system to build the native bridge, just need to link against art in addition to termux-provided stuff like glib/capstone/libffi but that should be fine (or against nativehelper, maybe it makes a difference on AOSP). I assume their build system should be able to cope with my Makefiles, maybe with some trivial changes. |
I'm trying to make this work with https://gitlab.com/android_translation_layer/android_translation_layer.
At first I tried using the build system we have for https://gitlab.com/android_translation_layer/art_standalone
(see patches below), but it seems that some files are missing, and arm is harcoded in some paths.
I assume there will be some other issues.
Would it be possible to simply use the original build system to build qemu, so as to sidestep these issues?
Is
__ANDROID__
being defined necessary for the qemu fork to work correctly, or is it only necessary to build for AOSP target?Seeing that there doesn't seem to be too much interest in this project as-is, would you like to help with getting this running with android_translation_layer (we like this compared to libhoudini, since it's open source, which is always a plus, and it's also practical since it means it can be modified to work more sanely with a standard Linux system)
The text was updated successfully, but these errors were encountered: