aout(4) [freebsd man page]
AOUT(4) BSD Kernel Interfaces Manual AOUT(4) NAME
aout -- kernel support for executing binary files in legacy a.out format SYNOPSIS
kldload a.out DESCRIPTION
The a.out(5) executable format was used before the release of FreeBSD 3.0. Since i386 was the only supported architecture at that time, a.out(5) executables can only be activated on platforms that support execution of i386 code, such as i386 and amd64. To add kernel support for old syscalls and old syscall invocation methods, place the following options in the kernel configuration file: options COMPAT_43 options COMPAT_FREEBSD32 The COMPAT_FREEBSD32 option is only required on 64-bit CPU architectures. The aout.ko module needs to be loaded with the kldload(8) utility in order to support the a.out(5) image activator: kldload aout Alternatively, to load the module at boot time, place the following line in loader.conf(5): aout_load="YES" The a.out(5) format was mainstream quite a long time ago. Reasonable default settings and security requirements of modern operating systems today contradict the default environment of that time and require adjustments of the system to mimic natural environment for old binaries. The following sysctl(8) tunables are useful for this: security.bsd.map_at_zero Set to 1 to allow mapping of process pages at address 0. Some very old ZMAGIC executable images require text mapping at address 0. kern.pid_max Old versions of FreeBSD used signed 16-bit type for pid_t. Current kernels use 32-bit type for pid_t, and allow process id's up to 99999. Such values cannot be represented by old pid_t, mostly causing issues for processes using wait(2) syscalls, for example shells. Set the sysctl to 30000 to work around the problem. kern.elf32.read_exec Set to 1 to force any accessible memory mapping performed by 32-bit process to allow execution, see mmap(2). Old i386 CPUs did not have a bit in PTE which disallowed execution from the page, so many old programs did not specify PROT_EXEC even for mapping of executable code. The sysctl forces PROT_EXEC if mapping has any access allowed at all. The setting is only needed if the host architecture allows non-executable mappings. SEE ALSO
execve(2), a.out(5), elf(5), sysctl(8) HISTORY
The a.out(5) executable format was used on ancient AT&T UNIX and served as the main executable format for FreeBSD from the beginning up to FreeBSD 2.2.9. In FreeBSD 3.0 it was superseded by elf(5). AUTHORS
The aout manual page was written by Konstantin Belousov <kib@FreeBSD.org>. BUGS
On 64bit architectures, not all wrappers for older syscalls are implemented. BSD
August 14, 2012 BSD
Check Out this Related Man Page
SVR4(4) BSD/i386 Kernel Interfaces Manual SVR4(4) NAME
svr4 -- System V Release 4 ABI support SYNOPSIS
To compile support for this ABI into the kernel, place the following line in your kernel configuration file: options COMPAT_SVR4 Alternatively, to load the ABI as a module at boot time, place the following line in loader.conf(5): svr4_load="YES" DESCRIPTION
The svr4 module provides limited System V Release 4 ABI (application binary interface) compatibility for userland applications. The module provides the following significant facilities: o An image activator for correctly branded elf(5) executable images o Special signal handling for activated images o SVR4 to native system call translation o STREAMS network API emulation (via the streams(4) loadable module, or by means of device streams in a kernel configuration file) o Mappings between FreeBSD and SVR4 ioctl(2) calls, or, where no such mappings exist, reverse-engineered implementations of the SVR4 calls. It is important to note that the SVR4 ABI support it not provided through an emulator. Rather, a true (albeit limited) "clean room" reverse- engineered ABI implementation is provided. LIMITATIONS
Because the provided ABI has been developed in ignorance of actual SVR4 source code, there are bound to be unforeseen interactions between SVR4 client applications and the emulated ABI which cause applications to malfunction. Additionally, some SVR4 operating systems do not adhere to the SVR4 ELF standard. In particular, Solaris does not set the ELF interpreter field in the ELF header to a value which would allow the kernel to correctly identify a client executable as an SVR4 application. Thus, in certain instances it is necessary to use the brandelf(1) utility to explicitly brand the executable, or to set the kern.fallback_elf_brand sysctl(8) variable to define a "default" ABI for unbranded executables. Value ELFOSABI_SOLARIS represents Solaris; ELFOSABI_SYSV represents other SysVR4 operating systems. See <sys/elf_common.h> for ELFOSABI branding definitions, and brandelf(1) for information on branding exe- cutables. The svr4 module can be linked into the kernel statically with the COMPAT_SVR4 kernel configuration option or loaded as required. The follow- ing command will load the module if it is neither linked into the kernel nor already loaded as a module: if ! kldstat -v | grep -E 'svr4elf' > /dev/null; then kldload svr4 > /dev/null 2>&1 fi The kernel will check for the presence of the streams(4) module, and load it if necessary. Note that dynamically linked SVR4 executables will require a suitable environment in /compat/svr4. For information on loading the svr4 kernel loadable module automatically on system startup, see rc.conf(5). This information applies regard- less of whether the svr4 module is statically linked into the kernel or loaded as a module. STREAMS emulation is limited but (largely) functional. Assuming the streams(4) module is loaded, a STREAMS handle can be obtained by opening one of the relevant files in /dev or /compat/svr4/dev. Internally, the streams(4) driver produces a socket descriptor and ``tags'' it with additional STREAMS state information before returning it to the client application. The svr4 environment uses the additional state informa- tion to recognize and manipulate emulated STREAMS handles when STREAMS-specific ioctl(2) calls are executed. The subset of STREAMS functionality which is provided is small, probably little more than what is required to enable programs on the Solaris CD sets to run. FILES
/compat/svr4 minimal SVR4 run-time environment /sys/compat/svr4/syscalls.master mappings between SVR4 syscalls and svr4 module entrypoints. SEE ALSO
brandelf(1), streams(4), elf(5) HISTORY
System V Release 4 ABI support first appeared in FreeBSD 4.0. The ABI was ported from an equivalent facility present in NetBSD 1.3 written by Christos Zoulas. BUGS
Emulation of signal handlers is buggy. Emulated connectionless STREAMS fail to receive data from the network in some circumstances (but succeed in others -- probably due to partic- ular ways of initializing them which the streams(4) module is mishandling, and interaction between STREAMS and poll(2)). Connection-oriented STREAMS appear to be functional. Ironically, this SVR4 emulator does not (yet) support SVR4 semaphores or shared memory. ports(7) to automatically create the /compat/svr4 environment do not exist. tar(1) archives containing pre-populated trees can be obtained from http://people.FreeBSD.org/~newton/freebsd-svr4/. Extensive testing has only really been carried out with Solaris 2.x binaries, with anecdotal reports of limited success coming from testers with early-revision SCO media. In theory, the basic SVR4 ABI should be constant across the set of vendors who produce SVR4 operating sys- tems, but in practice that is probably not the case. If necessary, future work can either implement additional kld(4) modules which produce functionality which contains OS-dependent departures from the behaviour which has been implemented in this ABI implementation. Alterna- tively, sysctl(8) variables could set the ``personality'' the environment should present to client applications. BSD
March 17, 2008 BSD