Provided by: gxemul_0.6.1-1build1_amd64 
NAME
gxemul — an experimental framework for full-system machine emulation
SYNOPSIS
gxemul [options] -e name [additional components and files ...]
gxemul [options] configfile
gxemul -V
gxemul -H
SYNOPSIS (OLD FRAMEWORK)
gxemul [machine, other, and general options] [file ...] gxemul [general options] @configfile
DESCRIPTION
gxemul is a framework for full-system computer architecture emulation. Several processor architectures
and machine types have been implemented. It is working well enough to allow unmodified "guest" operating
systems (e.g. NetBSD) to run inside the emulator, as if they were running on real hardware.
The emulator emulates (networks of) real machines. The machines may consist of ARM, MIPS, Motorola 88K,
PowerPC, and SuperH processors, and various surrounding hardware components such as framebuffers, busses,
interrupt controllers, ethernet controllers, disk controllers, and serial port controllers.
Note: Only very few emulated machine modes have been rewritten to use the new emulation framework
introduced in version 0.6.x, so there are two different ways to use the emulator. (Most emulation modes
and machines are only valid in the old framework.)
The options available for the new framework are:
-B Enables snapshotting (required for reverse execution/stepping).
-e name
Start with a machine based on template 'name'. The name may be followed by optional arguments in
parentheses, e.g.
gxemul -V -e 'testmips(cpu=R4400)'
Remember to use quotes if your shell gives special meaning to parentheses.
-H Display a list of available machine templates.
-q Start up in Quiet mode (i.e. suppress debug messages). If an error occurs during emulation which
stops execution and drops the user into the debugger, quiet mode is turned off.
-V Start up in interactive mode, paused. If this option is used, -q is ignored.
When using the -e option, the remainder of the command line consists of zero or more additional files to
load, or components to add to the emulation setup. Including these on the command line is equivalent to
using the 'add' command (although with a different syntax) in the interactive debugger. A simple example
is a file name to load into the emulated machine, but they can be more complex as well. See the Adding
Additional Components on the Command Line section below for more details.
When not using the -e option, the config file should be one that was previously saved from within the
emulator using the 'save' command.
Starting the emulator with the -V switch will bring you to the interactive debugger environment, without
starting the emulation.
ADDING ADDITIONAL COMPONENTS ON THE COMMAND LINE
The general syntax is:
existing_component_path:component(args)
If existing_component_path part is omitted, it is assumed to be cpu0. The component(args) part may be
written as just args, in which case the name of the component is autodetected, and the args is given as
an argument called "name" to that component.
gxemul For example, if the additional component/filename is just
netbsd-GENERIC
this will be equivalent to
cpu0:file(name=netbsd-GENERIC)
An attempt will be made to load the file netbsd-GENERIC into cpu0, which is the default component if none
is specified. This will most likely be expanded into root.machine0.mainbus0.cpu0. If cpu0 is ambiguous,
then this will not work; the specific cpu0 name must be supplied instead, like this:
machine3.mainbus0.cpu0:netbsd-GENERIC
Another example, using an SDL display component to show the contents of an emulated video framebuffer:
fb_videoram0:sdl()
Here, the existing component name (the framebuffer) and the component to add (the SDL display component)
are included, but no arguments.
RUNNING GUEST OPERATING SYSTEMS
Please read the HTML documentation for more details on how to run complete guest operating systems in the
emulator.
DESCRIPTION (OLD FRAMEWORK)
The emulator can be invoked in the following ways:
1. When emulating a complete machine, configuration options can be supplied directly on the command line.
2. Options can be read from a configuration file.
The easiest way to use the emulator is to supply settings directly on the command line.
The most important thing you need to supply is the file argument. This is the name of a binary file (an
ELF, a.out, COFF/ECOFF, SREC, or a raw binary image) which you wish to run in the emulator. This file
might be an operating system kernel, or perhaps a ROM image file. If more than one filename is supplied,
all files are loaded into memory, and the entry point (if available) is taken from the last file.
Apart from the name of a binary file, you must also use the -E and/or -e options to select which
emulation mode to use. This is necessary because the emulator cannot in general deduce this from the file
being executed. For example, a MIPS-based machine from DEC (a DECstation) is very different from a MIPS-
based machine from SGI. Use gxemul -H to get a list of available emulation modes.
There are three exceptions to the normal invocation usage mentioned above.
1. For DECstation emulation, if you have a bootable DECstation harddisk or CDROM image, then just
supplying the diskimage via the -d option is sufficient. The filename of the kernel can then be skipped,
as the emulator runs the bootblocks from the diskimage directly and doesn't need the kernel as a separate
file.
2. If you supply an ISO9660 CDROM disk image, then using the -j option to indicate a file on the CDROM
filesystem to load is sufficient; no additional kernel filename needs to be supplied on the command line.
3. For Dreamcast emulation, when booting e.g. a NetBSD/dreamcast CDROM image, it is enough to supply the
disk image (with the correct ISO partition start offset). Bootblocks will be read directly from the CDROM
image, and there is no need to supply the name of an external kernel on the command line.
Gzipped kernels are automatically unzipped, by calling the external gunzip program, both when specifying
a gzipped file directly on the command line and when loading such a file using the -j option.
Machine selection options:
-E t Try to emulate machine type t. This option is not always needed, if the -e option uniquely
selects a machine. (Use -H to get a list of types.)
-e st Try to emulate machine subtype st. Use this together with -E. (This option is not always
needed, if a machine type has no subtypes.)
Other options:
-C x Try to emulate a specific CPU type, x. This overrides the default CPU type for the machine being
emulated. (Use -H to get a list of available CPU types.)
-d [modifiers:]filename
Add filename as a disk image. By adding one or more modifier characters and then a colon (":") as
a prefix to filename, you can modify the way the disk image is treated. Available modifiers are:
b Specifies that this is a boot device.
c CD-ROM.
d DISK (this is the default).
f FLOPPY.
gH;S; Override the default geometry; use H heads and S sectors-per-track. (The number of
cylinders is calculated automatically.)
i IDE. (This is the default for most machine types.)
oOFS; Set the base offset for an ISO9660 filesystem on a disk image. The default is 0. A
suitable offset when booting from Dreamcast ISO9660 filesystem images, which are offset
by 11702 sectors, is 23965696.
r Read-only (don't allow changes to be written to the file).
s SCSI.
t Tape.
V Add an overlay filename to an already defined disk image. (A ID number must also be
specified when this flag is used. See the documentation for an example of how to use
overlays.)
0-7 Force a specific ID number.
For SCSI devices, the ID number is the SCSI ID. For IDE harddisks, the ID number has the
following meaning:
0 Primary master.
1 Primary slave.
2 Secondary master.
3 Secondary slave.
Unless otherwise specified, filenames ending with ".iso" or ".cdr" are assumed to be CDROM
images. Most others are assumed to be disks. Depending on which machine is being emulated, the
default for disks can be either SCSI or IDE. Some disk images that are very small are assumed to
be floppy disks. (If you are not happy with the way a disk image is detected, then you need to
use explicit prefixes to force a specific type.)
For floppies, the gH;S; prefix is ignored. Instead, the number of heads and cylinders are assumed
to be 2 and 80, respectively, and the number of sectors per track is calculated automatically.
(This works for 720KB, 1.2MB, 1.44MB, and 2.88MB floppies.)
-I hz Set the main CPU's frequency to hz Hz. This option does not work for all emulated machine modes.
It affects the way count/compare interrupts are faked to simulate emulated time = real world
time. If the guest operating system relies on RTC interrupts instead of count/compare interrupts,
then this option has no effect.
Setting the frequency to zero disables automatic synchronization of emulated time vs real world
time, and the count/compare system runs at a fixed rate.
-i Enable instruction trace, i.e. display disassembly of each instruction as it is being executed.
-J Disable instruction combinations in the dynamic translator.
-j n Set the name of the kernel to n. When booting from an ISO9660 filesystem, the emulator will try
to boot using this file. (In some emulation modes, eg. DECstation, this name is passed along to
the boot program. Useful names are "bsd" for OpenBSD/pmax, "vmunix" for Ultrix, or "vmsprite" for
Sprite.)
-M m Emulate m MBs of physical RAM. This overrides the default amount of RAM for the selected machine
type.
-N Display the number of executed instructions per second on average, at regular intervals.
-n nr Set the number of processors in the machine, for SMP experiments.
Note 1: The emulator allocates quite a lot of virtual memory for per-CPU translation tables. On
64-bit hosts, this is normally not a problem. On 32-bit hosts, this can use up all available
virtual userspace memory. The solution is to either run the emulator on a 64-bit host, or limit
the number of emulated CPUs to a reasonably low number.
Note 2: SMP simulation is not working very well yet; multiple processors are simulated, but
synchronization between the processors does not map very well to how real-world SMP systems work.
-O Force a "netboot" (tftp instead of disk), even when a disk image is present (for DECstation, SGI,
and ARC emulation).
-o arg Set the boot argument (mostly useful for DEC, ARC, or SGI emulation). Default arg for DEC is
"-a", for ARC/SGI it is "-aN", and for CATS it is "-A".
-p pc Add a breakpoint. pc can be a symbol, or a numeric value. (Remember to use the "0x" prefix for
hexadecimal values.)
-Q Disable the built-in (software-only) PROM emulation. This option is useful for experimenting with
running raw ROM images from real machines. The default behaviour of the emulator is to "fake"
certain PROM calls used by guest operating systems (e.g. NetBSD), so that no real PROM image is
needed.
-R Use a random bootstrap cpu, instead of CPU nr 0. (This option is only meaningful together with
the -n option.)
-r Dump register contents for every executed instruction.
-S Initialize emulated RAM to random data, instead of zeroes. This option is useful when trying to
trigger bugs in a program that occur because the program assumed that uninitialized memory
contains zeros. (Use with care.)
-s flags:filename
Gather statistics based on the current emulated program counter value, while the program
executes. The statistics is actually just a raw dump of all program counter values in sequence,
suitable for post-analysis with separate tools. Output is appended to filename.
The flags should include one or more of the following type specifiers:
v Virtual. This means that the program counter value is used.
p Physical. This means that the physical address of where the program is actually running
is used.
i Instruction call. This type of statistics gathering is practically only useful during
development of the emulator itself. The output is a list of addresses of instruction call
functions (ic->f), which after some post-processing can be used as a basis for deciding
when to implement instruction combinations.
The flags may also include the following optional modifiers:
d Disabled at startup.
o Overwrite the file, instead of appending to it.
Statistics gathering can be enabled/disabled at runtime by using the "statistics_enabled = yes"
and "statistics_enabled = no" debugger commands.
When gathering instruction statistics using the -s option, instruction combinations are always
disabled (i.e. an implicit -J flag is added to the command line).
-T Halt if the emulated program attempts to access non-existing memory.
-t Show a trace tree of all function calls being made.
-U Enable slow_serial_interrupts_hack_for_linux.
-X Use X11. This option enables graphical framebuffers.
-x Open up new xterms for emulated serial ports. The default behaviour is to open up xterms when
using configuration files, or if X11 is enabled. When starting up a simple emulation session with
settings directly on the command line, and neither -X nor -x is used, then all output is confined
to the terminal that gxemul started in.
-Y n Scale down framebuffer windows by n x n times. This option is useful when emulating a very large
framebuffer, and the actual display is of lower resolution. If n is negative, then there will be
no scaledown, but emulation of certain graphic controllers will be scaled up by -n times instead.
E.g. Using -2 with VGA text mode emulation will result in 80x25 character cells rendered in a
1280x800 window, instead of the normal resolution of 640x400.
-Z n Set the number of graphics cards, for emulating a dual-head or tripple-head environment. (Only
for DECstation emulation so far.)
-z disp
Add disp as an X11 display to use for framebuffers.
General options:
-c cmd Add cmd as a command to run before starting the simulation. A similar effect can be achieved by
using the -V option, and entering the commands manually.
-D Causes the emulator to skip a call to srandom(). This leads to somewhat more deterministic
behaviour than running without this option. However, if the emulated machine has clocks or timer
interrupt sources, or if user interaction is taking place (e.g. keyboard input at irregular
intervals), then this option is meaningless.
-H Display a list of available CPU types and machine types. (Most of these don't work. Please read
the HTML documentation included in the gxemul distribution for details on which modes that
actually work.)
-h Display a list of all available command line options.
-k n Set the size of the dyntrans cache (per emulated CPU) to n MB. The default size is 48 MB.
-K Force the single-step debugger to be entered at the end of a simulation.
-q Quiet mode; this suppresses startup messages.
-V Start up in the single-step debugger, paused. If this option is used, -q is ignored.
-v Increase verbosity (show more debug messages). This option can be used multiple times.
Configuration file startup:
@ configfile
Start an emulation based on the contents of configfile.
For more information, please read the HTML documentation in the doc/ subdirectory of the gxemul
distribution.
OLD FRAMEWORK EXAMPLES
The following command will start NetBSD/pmax on an emulated DECstation 5000/200 (3MAX):
gxemul -e 3max -d nbsd_pmax.img
nbsd_pmax.img should be a raw disk image containing a bootable NetBSD/pmax filesystem.
The following command will start an emulation session based on settings in the configuration file
"mysession". The -v option tells gxemul to be verbose.
gxemul -v @mysession
If you have compiled the small Hello World program mentioned in the gxemul documentation, the following
command will start up an emulated test machine in "paused" mode:
gxemul -E oldtestmips -V hello_mips
Paused mode means that you enter the interactive single-step debugger directly at startup, instead of
launching the Hello World program.
The paused mode is also what should be used when running "unknown" files for the first time in the
emulator. E.g. if you have a binary which you think is some kind of MIPS ROM image, then you can try the
following:
gxemul -vv -E baremips -V 0xbfc00000:image.raw
You can then use the single-stepping functionality of the built-in debugger to run the code in the ROM
image, to see how it behaves. Based on that, you can deduce what machine type it was actually from (the
baremips machine is not a real machine), and perhaps try again with another emulation mode.
In general, however, real ROM images require much more emulation detail than GXemul provides, so they can
usually not run.
Please read the HTML documentation for more details.
BUGS
There are many bugs. Some of the known bugs are mentioned in the TODO file in the gxemul source
distribution, some are marked as TODO in the source code itself.
Most emulation modes are legacy (Old framework) modes, which have not yet been rewritten to use the new
framework. The documentation is most likely buggy, in the sense that it describes things from the old
framework when the new one applies, and/or vice versa.
gxemul is in general not cycle-accurate; it does not simulate individual pipe-line stages or penalties
caused by branch-prediction misses or cache misses, so it cannot be used for accurate simulation of any
actual real-world processor.
gxemul is in general not timing-accurate. Many emulation modes try to make the guest operating system's
clock run at the same speed as the host clock. However, the number of instructions executed per clock
tick can obviously vary, depending on the current CPU load on the host.
AUTHOR
GXemul is Copyright (C) 2003-2018 Anders Gavare <gavare@gmail.com>
See http://gxemul.sourceforge.net/ for more information. For other Copyright messages, see the
corresponding parts of the source code and/or documentation.
Debian NOVEMBER 2018 GXEMUL(1)