Processors (ARM, MIPS, PowerPC) are emulated using dynamic translation. However, unlike some other dynamically translating emulators, GXemul does not currently generate native code, only a "runnable intermediate representation", and will thus run on any host architecture, without the need to implement per-architecture backends.

The emulator can be invoked in the following ways:

1. When emulating a complete machine, configuration options can be entered 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, it is also necessary to select which specific emulation mode to use. For example, a MIPS-based machine from DEC (a DECstation) is very different from a MIPS-based machine from SGI. Use -H to get a list of available emulation modes.

There are two exceptions to the normal invocation usage mentioned above. The first is 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.) The second is if you supply an ISO9660 CDROM disk image. You may then use the -j option to indicate which file on the CDROM filesystem that should be loaded into emulated memory.

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.)

r

Read-only (don't allow changes to be written to the file).

s

SCSI.

t

Tape.

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.)

-G port

Pause at startup, and listen to TCP port port for incoming remote GDB connections. The emulator starts up in paused mode, and it is up to the remote GDB instance to start the session.

-I x

Emulate clock interrupts at x Hz. (This affects emulated clock devices only, not actual runtime speed. This disables automatic clock adjustments, which is otherwise turned on.) (This option is probably only valid for DECstation emulation.)

-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.

When gathering instruction statistics using the -s option, instruction combinations are always disabled (i.e. an implicit -J is added to the command line).

If a value is missing (e.g. the end-of-page slot does not really have a known physical address), it is written out as just a dash ("-").

-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 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

Guarantee fully deterministic behavior. Normally, the emulator calls srandom() with a seed based on the current time at startup. When the -D option is used, the srandom() call is skipped, which should cause two subsequent invocations of the emulator to be identical, if all other settings are identical and no user input is taking place. (If this option is used, then -I must also be used.)

-H

Display a list of available CPU types, machine types, and userland emulation modes. (Most of these don't work. Please read the documentation included in the distribution for details on which modes that actually work. Userland emulation is not included in stable release builds, since it doesn't work yet.)

-h

Display a list of all available command line options.

-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.

-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 documentation in the doc/ subdirectory of the distribution.

"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 documentation, the following command will start up an emulated test machine in "paused" mode:

"gxemul -E testmips -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 documentation for more details.

Userland (syscall-only) emulation doesn't really work yet.

The documentation sometimes only reflects the way things worked with the old MIPS emulation mode (prior to 0.4.0), and it is incorrect when applied to current releases.

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.

is not timing-accurate, i.e. clocks inside the emulator are in general not at all synched with clocks in the real world. There are a few exceptions to this rule (the mc146818 device tries to automagically adjust emulated timer ticks to actual emulation speed).

See http://gavare.se/gxemul/ for more information. For other Copyright messages, see the corresponding parts of the source code and/or documentation.