No description
Find a file
Eric Blake 0d52542da2
qapi: Simplify semantics of visit_next_list()
The semantics of the list visit are somewhat baroque, with the
following pseudocode when FooList is used:

start()
for (prev = head; cur = next(prev); prev = &cur) {
visit(&cur->value)
}

Note that these semantics (advance before visit) requires that
the first call to next() return the list head, while all other
calls return the next element of the list; that is, every visitor
implementation is required to track extra state to decide whether
to return the input as-is, or to advance. It also requires an
argument of 'GenericList **' to next(), solely because the first
iteration might need to modify the caller's GenericList head, so
that all other calls have to do a layer of dereferencing.

Thankfully, we only have two uses of list visits in the entire
code base: one in spapr_drc (which completely avoids
visit_next_list(), feeding in integers from a different source
than uint8List), and one in qapi-visit.py. That is, all other
list visitors are generated in qapi-visit.c, and share the same
paradigm based on a qapi FooList type, so we can refactor how
lists are laid out with minimal churn among clients.

We can greatly simplify things by hoisting the special case
into the start() routine, and flipping the order in the loop
to visit before advance:

start(head)
for (tail = *head; tail; tail = next(tail)) {
visit(&tail->value)
}

With the simpler semantics, visitors have less state to track,
the argument to next() is reduced to 'GenericList *', and it
also becomes obvious whether an input visitor is allocating a
FooList during visit_start_list() (rather than the old way of
not knowing if an allocation happened until the first
visit_next_list()). As a minor drawback, we now allocate in
two functions instead of one, and have to pass the size to
both functions (unless we were to tweak the input visitors to
cache the size to start_list for reuse during next_list, but
that defeats the goal of less visitor state).

The signature of visit_start_list() is chosen to match
visit_start_struct(), with the new parameters after 'name'.

The spapr_drc case is a virtual visit, done by passing NULL for
list, similarly to how NULL is passed to visit_start_struct()
when a qapi type is not used in those visits. It was easy to
provide these semantics for qmp-output and dealloc visitors,
and a bit harder for qmp-input (several prerequisite patches
refactored things to make this patch straightforward). But it
turned out that the string and opts visitors munge enough other
state during visit_next_list() to make it easier to just
document and require a GenericList visit for now; an assertion
will remind us to adjust things if we need the semantics in the
future.

Several pre-requisite cleanup patches made the reshuffling of
the various visitors easier; particularly the qmp input visitor.

Backports commit d9f62dde1303286b24ac8ce88be27e2b9b9c5f46 from qemu
2018-02-23 19:50:26 -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 include: Move RAMList to ramlist.h 2018-02-20 08:47:51 -05:00
msvc qapi: Simplify semantics of visit_next_list() 2018-02-23 19:50:26 -05:00
qemu qapi: Simplify semantics of visit_next_list() 2018-02-23 19:50:26 -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: Move hook freeing code to its own function 2018-02-22 20:00:32 -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.