5e – user–mode ARM emulation|
5e [ –npbF ] text [ arguments ]|
5e simulates the execution of an ARM binary in a Plan 9 environment.
Unlike its predecessor vi(1) it supports, among others, the syscalls
rfork (see fork(2)) and exec(2), which allows for the execution
of threaded programs (e.g., rio(1) or catclock (see games(1)).
5e executes the specified binary text, which is prepended by /bin if it does not begin with a slash, dot or hash sign. Unless –n is specified, /bin is replaced by the union of /arm/bin and /rc/bin.
Unlike vi(1), 5e(1) does not provide built–in debugging facilities. It does provide emulation of the /proc directory, if the –p flag is specified, to attach a proper debugger like acid(1). There is no equivalent of the profiling facilities, no caches or TLBs are simulated, either.
5e(1) currently has three options.
The host is required to be little endian and is assumed to have
a floating point implementation conforming to IEEE 754.|
Broken processes are simulated in a rather unsatisfactory manner. The –b option leaks memory. The emulator does not post sys: notes.
Obscure opcodes, in particular uncommon operations on R15, are not implemented.
Accesses spanning segment boundaries will be treated as page faults. Many syscalls such as pread (see read(2)) will shuffle data around (in most cases unnecessarily) if invoked on potentially shared segments of variable length, in particular the bss segment.
FPA emulation leaves much to be desired, rounding modes are ignored, all calculations are performed at extended precision. Floating point exceptions crash the emulator.
Several syscalls, most notably the segattach(2) family, are not implemented (this should not be hard to fix). The emulator notes the value of errstr(2) only under obvious circumstances; with most syscalls only if the return value is negative.
/proc emulation is more than unsatisfactory.
The text argument should behave more like it would if it had been entered as an argument to rc(1).
5e first appeared in 9front (June, 2011).|