| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang and llvm-gcc don't support global register variable (GRV) crucial
to emulator (where a register is reserved to point to target architecture
state for better code-gen). Clang and llvm-gcc are provided in recent
Xcode to replace the original gcc with GRV support. MacOSX developers
may accidentally install newer Xcode and break emulator.
This CL allows emulator (and the rest of Android tree) to build but forces
emulator to quit if it's built w/o GRV support. Developers build
Android tree with clang or llvm-gcc can still get good system image,
but they have to use emulators built the other way or from SDKs to run it.
Related CL & bug entry:
https://android-review.googlesource.com/#/c/33011
http://code.google.com/p/android/issues/detail?id=32577
Change-Id: Ia585dd7bf9783e2ff4c114b4f0ec20b89684ab57
|
| |
|
|
|
|
|
| |
The Xcode 4.3 compiler doesn't have support for global register variables so
this patch ensures that the register keyword is not incuded for that compiler.
Signed-off-by: Al Sutton <al@funkyandroid.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new translator has the following benefits:
- faster emulation of ARMv5TE code (through improved JIT)
- proper support for ARMv7 and NEON
- rebuilding the full-eng platform images for ARMv7-A results
in additionnal speed increases (a.k.a. Thumb-2 rocks!).
Note that, as an interesting side effect, NEON machine code is generally
slower than the equivalent C code it is supposed to replace when run inside
the emulator. This can be explained by the fact that for now the translator
simply translates each NEON instruction into a series of sequential host
instructions (and also requires over-head for packing/unpacking/saturation/
etc...).
This change has been tested by running the "full-eng" platform image
rebuilt for ARMv7-A and Neon and using an appropriate kernel image
(prebuilt/android-arm/kernel/kernel-qemu-armv7). The system could boot
and seems to work perfectly. Not a single issue has been experienced
during testing. On a 2.4 GHz Xeon CPU, the image boots in about 25 seconds
(compared to 40 seconds for a vanilla one without this emulator patch).
Thanks to Peter Maydell at Linaro and ARM with his hard work to make this
happen (first in upstream, and now on Android).
This integration is based on the Meego git repository
(git://gitorious.org/qemu-maemo/qemu.git) using the following hash:
7e2d65b0c95c865b1fa6d3d4948e8e822b9ac2fd
On top of which, the following upstream patch has been applied
(with recommendation from Peter):
b7fa9214d8d4f57992c9acd0ccb125c54a095f00
(We chose this repository because it was the closest to the previous
integrate. We will probably use the Linaro ones for future work on this
part of the emulator).
Change-Id: I54837e3d2e908b2380d158411d7a9813630e7e4e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change integrates many changes from the upstream QEMU sources.
Its main purpose is to enable correct ARMv6 and ARMv7 support to the
Android emulator. Due to the nature of the upstream code base, this
unfortunately also required changes to many other parts of the source.
Note that to ensure easier integrations in the future, some source files
and directories that have heavy Android-specific customization have been
renamed with an -android suffix. The original files are still there for
easier integration tracking, but *never* compiled. For example:
net.c net-android.c
qemu-char.c qemu-char-android.c
slirp/ slirp-android/
etc...
Tested on linux-x86, darwin-x86 and windows host machines.
|
| | |
|
| | |
|
| | |
|
| |
|
