Unicorn CPU emulator framework (ARM, AArch64, M68K, Mips, Sparc, X86)
Go to file
Eric Blake b9b76f9b4b
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!

There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.

2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.

Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.

Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]

Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).

Backports commit 9f08c8ec73878122ad4b061ed334f0437afaaa32 from qemu
2018-02-19 18:55:35 -05:00
bindings link to Crystal binding 2017-12-23 00:26:40 +08:00
docs Added note about installing tests dependencies on Mac OS X. Added note about tests failing when required architecture support is disabled in build. (#908) 2017-10-12 19:56:00 +08:00
include target-i386: Correct unicorn macro 2018-02-19 01:00:47 -05:00
msvc qapi: Simplify gen_visit_fields() error handling 2018-02-19 18:45:05 -05:00
qemu qapi: Lazy creation of array types 2018-02-19 18:55:35 -05:00
samples Fixed register mistake in comments (#894) 2017-09-17 16:40:01 +07:00
tests add 64-bit test demonstrating setting MSRs and FS/GS segments (#901) 2017-09-29 04:26:23 +08:00
.appveyor.yml MSYS test (#852) 2017-06-25 10:11:35 +08:00
.gitignore arm64eb: add support for ARM64 big endian. 2017-04-24 23:30:01 +08:00
.travis.yml use new travis osx image and brew (#935) 2018-01-05 10:29:49 +08:00
AUTHORS.TXT import 2015-08-21 15:04:50 +08:00
Brewfile Update Brewfile 2017-09-30 17:36:44 +07:00
ChangeLog update ChangeLog 2017-04-20 13:28:02 +08:00
config.mk Fix document file extension 2016-08-08 17:33:49 +09:00
COPYING import 2015-08-21 15:04:50 +08:00
COPYING.LGPL2 LGPL2 for all header files under include/unicorn/ 2017-12-16 10:08:42 +08:00
COPYING_GLIB glib_compat: add COPYING_GLIB 2016-12-27 10:15:08 +08:00
CREDITS.TXT update CREDITS.TXT 2017-04-25 12:56:47 +08:00
install-cmocka-linux.sh Start moving examples in S files (#851) 2017-06-25 10:14:22 +08:00
list.c callback to count number of instructions in uc_emu_start() should be executed first. fix #727 2017-06-16 13:22:38 +08:00
make.sh Added MSVC support for arm64eb. 2017-04-25 14:23:58 +10:00
Makefile crypto: introduce new module for computing hash digests 2018-02-17 15:23:17 -05:00
msvc.bat add msvc.bat 2017-04-21 15:35:40 +08:00
pkgconfig.mk bump extra version to 2 2017-04-21 15:30:40 +08:00
README.md add Clojure 2017-12-23 00:32:33 +08:00
uc.c uc: Handle freeing of multiple address spaces 2018-02-18 21:36:50 -05:00
windows_export.bat Make the call out to visual studio extremely resilient 2017-01-02 03:32:48 -08:00

Unicorn Engine

Join the chat at https://gitter.im/unicorn-engine/chat

Build Status Build status

Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU.

Unicorn offers some unparalleled features:

  • Multi-architecture: ARM, ARM64 (ARMv8), M68K, MIPS, SPARC, and X86 (16, 32, 64-bit)
  • Clean/simple/lightweight/intuitive architecture-neutral API
  • Implemented in pure C language, with bindings for Crystal, Clojure, Visual Basic, Perl, Rust, Ruby, Python, Java, .NET, Go, Delphi/Free Pascal and Haskell.
  • Native support for Windows & *nix (with Mac OSX, Linux, *BSD & Solaris confirmed)
  • High performance via Just-In-Time compilation
  • Support for fine-grained instrumentation at various levels
  • Thread-safety by design
  • Distributed under free software license GPLv2

Further information is available at http://www.unicorn-engine.org

License

This project is released under the GPL license.

Compilation & Docs

See docs/COMPILE.md file for how to compile and install Unicorn.

More documentation is available in docs/README.md.

Contact

Contact us via mailing list, email or twitter for any questions.

Contribute

If you want to contribute, please pick up something from our Github issues.

We also maintain a list of more challenged problems in a TODO list.

CREDITS.TXT records important contributors of our project.