lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:23:35 -05:00
parent b50063d9b3
commit 9912ec445d
12689 changed files with 3135349 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/bin-format/E-MAILING A BINARY FILE.files/webmaster.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.7 KiB

97
docs/bin-format/E-MAILING A BINARY FILE.htm Normal file
View File

@@ -0,0 +1,97 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0069)http://www.ece.northwestern.edu/CSEL/FAQ/e-mailing_a_binary_file.html -->
<HTML><HEAD><TITLE>E-MAILING A BINARY FILE</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type><LINK
href="mailto:webmaster@ece.nwu.edu" rev=MADE>
<META content="MSHTML 5.00.3502.5390" name=GENERATOR></HEAD>
<BODY>
<P>Audience: Intermediate ECE UNIX system users Summary: Tells how to send
binary (and other non-ASCII) files through electronic mail. From: ECE system
administration office
<HR>
<P>
<H1>E-MAILING A BINARY FILE</H1><A name=1>
<H2>Contents</H2></A>
<P>I. Overview
<P>II. General Procedure
<P>III. Example
<P>IV. For More Information <A name=2>
<H3>I. Overview</H3></A>The ECE electronic mail system expects your mail
messages to consist entirely of ASCII characters. But what if you want to
include a binary (or other non-ASCII) file in an e- mail message? This document
describes one way to do this.
<P>You use a standard UNIX utility called "uuencode" to create a special
all-ASCII representation of your binary file. The resulting text file can then
be sent through e-mail just like any text file.
<P>The recipient of the encoded file then uses another UNIX utility called
"uudecode" to put the file back into its original binary form. <A name=3>
<H3>II. General Procedure</H3></A>
<P>The SENDER of the binary file should...
<OL>
<LI>Encode the file: </LI></OL>
<P>uuencode &lt;binfile&gt; &lt;binfile&gt; &gt; &lt;txtfile&gt; &lt;RET&gt;
<P>2. E-mail the encoded file:
<P>Include &lt;txtfile&gt; in e-mail message as an ordinary text file.
<P>The RECIPIENT of the e-mail message should...
<OL>
<LI>Save the e-mail message to a file.
<LI>Decode the file: </LI></OL>
<P>uudecode &lt;encodedfile&gt; &lt;RET&gt; <A name=4>
<H3>III. Example</H3></A>Let's say you have a binary file called "a.out" that
you want send to your friend Liza.
<P>
<OL>
<LI>You encode the file: </LI></OL>You enter the following command to create an
all-ASCII representation of the file "a.out" called "a.txt".
<P>uuencode a.out a.out &gt; a.txt &lt;RET&gt;
<P>(Note that you need to specify the filename "a.out" twice.)
<P>2. You add a personal note:
<P>You open up the file "a.txt" in your usual text editor, and add a note to
Liza at the top.
<P>Your completed message looks like this --
<P>Dear Liza,
<P>Here's my program "a.out". Decode it with "uudecode". Let me know what you
think!
<P>--Gern <PRE> begin 755 a.out
M*B "E *@!)0"0 H7 0U"+A8 , C" &amp;'H@) 0* 0!
M ! @, 0 $ (N&lt;(Z @0 ("P$ ! @, 0 )WC
M"!$ B0$B'L0 2Y(0( "L$ (D@.@7$ $N4$" @@*(@
...
M "6$N 2F! %D "N:$ 4+P "*X5XE01 (D!(A^T
M",(#H&amp;B D ! H "R BN%&gt;(HD 3 $I(0 !&amp;4$" '%R
end
</PRE>
<P>3. You mail the message:
<P>Now you mail the file "a.txt" to Liza, whose e-mail address you know to be
"liza@merle.acns.nwu.edu".
<P>(If you use the mail program Elm, you can type "elm liza@merle.acns.nwu.edu
&lt; a.txt &lt;RET&gt;" at the UNIX prompt.)
<P>The next time Liza reads her mail, she sees your message. In order to restore
the encoded file you sent her to its original format, she does the following two
things:
<OL>
<LI>Liza saves your message to a file: </LI></OL>
<P>From within her mail program, Liza saves your message in her current
directory under the name "gern". (Different mail programs have different ways
for doing this. From the main screen of Elm, for example, she would select your
message and type "s gern &lt;RET&gt;".)
<P>2. Liza decodes the file:
<P>She quits her mail program, and types the following command at the UNIX
prompt:
<P>uudecode gern &lt;RET&gt;
<P>And that's it! Liza now has an exact copy of your ori- ginal binary file
"a.out" in her current directory! <A name=5>
<H3>IV. For More Information</H3></A>
<UL>
<LI>See the man page for "uuencode".
<LI>Send a detailed message to the ECE system administrator at the e-mail
address "root@ece.nwu.edu".
<LI>Drop by the ECE system administration office in Tech M334. </LI></UL>
<P>
<HR>
<ADDRESS><A href="mailto:webmaster@ece.nwu.edu"><IMG alt=""
src="E-MAILING A BINARY FILE.files/webmaster.gif">
webmaster@ece.nwu.edu</A>.<BR>Last Updated: $Date: 2000/02/22 15:47:08 $
</ADDRESS></BODY></HTML>

BIN
docs/bin-format/Linux Frontiers.files/elfvsaout.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

310
docs/bin-format/Linux Frontiers.htm Normal file
View File

@@ -0,0 +1,310 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0048)http://www.stllinux.org/meeting_notes/1995/0817/ -->
<?xml version="1.0" encoding="UTF-8"?><HTML lang=en xml:lang="en"
xmlns="http://www.w3.org/1999/xhtml"><HEAD><TITLE>STLLUG 08/17/1995 - Linux Frontiers</TITLE>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type><!-- #(@) $Id: index.html,v 1.3 2002/01/14 02:09:24 mike808 Exp $ --><!-- Copyright 2001 by stllinux.org, --><!-- St. Louis, Missouri, U.S.A. --><!-- All rights reserved. Licensed for use on www.stllinux.org. --><!-- All brands and product names are trademarks or registered trademarks of --><!-- their respective companies. -->
<META content="MSHTML 5.00.3502.5390" name=GENERATOR></HEAD>
<BODY aLink=#ff0000 bgColor=#ffffff link=#cc0000 text=#000000 vLink=#000099><!-- BEGIN BODY TEXT --><FONT size=+2>STLLUG - St. Louis Linux
User Group</FONT><BR>08/17/1995 : Linux Frontiers<BR><FONT size=1>Presenter: <A
href="http://www.feldt.com/">Matthew Feldt</A></FONT>
<HR>
<H1><I>Linux Frontiers</I></H1>
<P><FONT size=5><I>Matt Welsh<BR>O'Reilly and Associates, Inc.</I></FONT> </P>
<HR>
<H3>What is Linux?</H3>
<UL>
<LI>Free 32-bit UNIX system for the x86
<LI>Developed by volunteers on Internet
<LI>Distributed via FTP and CD-ROM by many vendors
<LI>Supports full preemptive multitasking, TCP/IP networking, and much more
<LI>Large hardware support base
<LI>Thousands of free applications available: X11R6, Emacs, TeX, gcc, you name
it
<LI>Commercial apps emerging including WordPerfect and Mathematica
<LI>Being ported to Alpha, m68k, SPARC, MIPS, and others </LI></UL>
<HR>
<H3>More Information about Linux</H3>
<UL>
<LI>Running Linux, O'Reilly and Associates 1995
<LI><A href="http://sunsite.unc.edu/mdw/linux.html">WWW:
http://sunsite.unc.edu/mdw/linux.html</A>
<LI><A href="ftp://sunsite.unc.edu:/pub/Linux/docs">FTP:
sunsite.unc.edu:/pub/Linux/docs</A>
<LI>comp.os.linux.* USENET newsgroups </LI></UL>
<HR>
<H3>Overview</H3>
<DL>
<DT><B>ELF Support</B>
<DD>Executable and Linkable Format: AT&amp;T Binary Spec for Linux
<DT><B>iBCS2 Emulation</B>
<DD>The standard for x86 UNIX binaries
<DT><B>WINE: The Windows Emulator</B>
<DD>Run MS-Windows applications under Linux/X11R6
<DT><B>Loadable Kernel Modules</B>
<DD>Load and unload kernel drivers dynamically </DD></DL>
<HR>
<H3>ELF</H3>
<DL>
<DT><B>Executable and Linkable Format</B>
<DD>Defines binary format for executables, object files, and libraries.
<DT><B>a.out and COFF</B>
<DD>Two other binary formats: a.out originated at BSD, and used initially by
Linux.
<DT><B>Advantages of ELF</B>
<UL>
<LI>More flexible and powerful than a.out, simplifies compilers and linkers.
Also more complex, and more processing overhead is required in some cases.
<LI>Makes it very easy to build and use shared libraries.
<LI>More interoperable with other systems and tools. </LI></UL></DT></DL>
<HR>
<H3>ELF vs. a.out format</H3>
<CENTER><IMG alt="ELF vs. a.out file format" border=0 height=307
src="Linux Frontiers.files/elfvsaout.gif" width=402></CENTER>
<HR>
<H3>Building ELF Shared Libraries</H3>
<OL>
<LI>Build objects as PIC (position-independent) code:<BR><CODE>gcc -fPIC -O -c
foo.c -o foo.o</CODE>
<LI>Link objects into shared object:<BR><CODE>gcc -shared -o libfoo.so foo.o
bar.o ...</CODE>
<LI>To use shared libs, just link as normal:<BR><CODE>gcc -O -o baz baz.o
-lfoo</CODE><BR>Uses libfoo.so shared lib automatically. </LI></OL>
<HR>
<H3>Dynamic Linking and Loading</H3>
<DL>
<DT><B>ld.so</B>
<DD>performs dynamic linking for executables at load time
<DT><B>libdl.a</B>
<DD>allows you to do dynamic linking within a program<BR>* dlopen() opens
shared object, returns handle<BR>* dlsym() looks up symbol from shared object,
returns pointer<BR>Can then use pointer (function or object) as usual </DD></DL>
<HR>
<H3>Dynamic Linking Example</H3><PRE> /* Open shared obj libfoo.so
* RTLD_LAZY: Only relocate as necessary
*/
handle = dlopen( "libfoo.so", RTLD_LAZY );
/* Look up symbol for thefunction() */
funcptr = ( funcptr_t )dlsym( handle, "thefunction" );
/* Call function from shared object */
( *fptr )();
</PRE>Dynamic linking with ELF is easy and fun!
<HR>
<H3>Upgrading to ELF</H3>
<P>All tools at <A
href="ftp://sunsite.unc.edu:/pub/Linux/GCC">ftp://sunsite.unc.edu:/pub/Linux/GCC</A>
</P><B>You will need:</B>
<UL>
<LI>Post-1.1.52 kernel
<LI>ld.so-1.7.3.tar.gz -- new runtime linker
<LI>libc-5.0.9 -- new ELF-based C library
<LI>gcc-2.7.0 -- gcc with ELF support
<LI>binutils-2.6.2.l17 -- ld, gas, etc. for ELF
<LI>The Linux ELF-HOWTO -- a must! </LI></UL>
<HR>
<H3>iBCS2 Support</H3><B>Intel Binary Compatibility Spec, v.2</B>
<UL>
<LI>Standard for user/kernel interface for x86 UNIX systems, including SVR3,
SVR4, BSD, Xenix, etc.
<LI>Defines system call interface, signal behavior, network layer interface,
etc.
<LI>Nothings perfect: Many vendor-specific extensions </LI></UL><B>iBCS2 for
Linux</B>
<UL>
<LI>Allows binaries from other x86 UNIX systems to run under Linux
<LI>This includes commercial applications! </LI></UL>
<HR>
<H3>iBCS2 Features</H3><B>Kernel emulator</B>
<UL>
<LI>Loads binaries of appropriate format (ELF, COFF, etc.)
<LI>Provides LCALL7 trap for system calls </LI></UL><B>Personalities</B>
<UL>
<LI>Each process has a "personality" chosen from binary format at load time
<LI>Maps system calls, error codes, and signal numbers between application and
kernel
<LI>Also used to choose system-call behavior on per-process basis (e.g.,
select timeout) </LI></UL>
<HR>
<H3>iBCS2 Shared libraries</H3>
<UL>
<LI>Dynamically-linked binaries need an iBCS2-compliant libc.so
<LI>iBCS2 team has modified libc sources for this
<LI>Statically-linked binaries (e.g., WordPerfect) have no problem
<LI>XFree86 shared libraries can be used for X apps
<LI>libsocket, libnsl used by some systems has limited support
<LI>You may be able to use native shared libs under Linux (with ELF support)
if license permits </LI></UL>
<HR>
<H3>Supported Systems</H3><B>Binary formats</B>
<UL>
<LI>a.out, ELF, COFF, or x.out </LI></UL><B>O/S emulations</B>
<UL>
<LI>i386 BSD (386BSD, FreeBSD, NetBSD, BSDI/386), very alpha.
<LI>SVR4 (Interactive, Unixware, USL, Dell etc.)
<LI>SVR3 generic
<LI>SCO (SVR3 with extensions for symlinks and long filenames)
<LI>Wyse V/386 (SVR3 with extensions for symlinks)
<LI>Xenix V/386 (386 small model binaries only)
<LI>Xenix 286 </LI></UL>
<HR>
<H3>Getting the Emulator</H3>
<P>Files at <A
href="ftp://tsx-11.mit.edu/pub/linux/BETA/ibcs2">tsx-11.mit.edu/pub/linux/BETA/ibcs2</A>
</P>
<DL>
<DT><B>ibcs-1.2-yymmdd.tar.gz</B>
<DD>The kernel emulator
<DT><B>sco-libs-yymmdd.tar.gz</B>
<DD>SCO shared libs
<DT><B>svr4-shlib-yymmdd.tar.gz</B>
<DD>SVR4 shared libs
<DT><B>libc_s-yymmdd.tar.gz</B>
<DD>iBCS2 libc source </DD></DL>
<P>Mail <I><A
href="mailto:majordomo@vger.rutgers.edu">majordomo@vger.rutgers.edu</A></I> for
info on the linux-ibcs2 mailing list </P>
<HR>
<H3>WINE: The Windows Emulator</H3><B>What is it?</B>
<UL>
<LI>An MS-Windows emulator for x86-based UNIX and X11
<LI>Loads MS-Windows executables into 32-bit UNIX process
<LI>Emulates Windows API by catching calls and translating to X11 equivalents
</LI></UL><B>How well does it work?</B>
<UL>
<LI>Most applets installed with Windows run to some extent
<LI>Solitaire works!
<LI>A number of PD/shareware MSW games run
<LI>No reports of major apps yet---except occasionally Quicken </LI></UL>
<HR>
<H3>Where can I get WINE?</H3>
<UL>
<LI><A
href="ftp://sunsite.unc.edu/pub/Linux/ALPHA/wine">/pub/Linux/ALPHA/wine</A> on
sunsite.unc.edu
<LI>Most recent is Wine-yymmdd.tar.gz
<LI>First get the Wine.FAQ and related docs
<LI>See comp.emulators.ms-windows.wine </LI></UL>
<HR>
<H3>WINE Program Loader</H3>
<UL>
<LI>Loads MS-Windows .EXE file into 32-bit process address space
<LI>All WINE code itself is 32-bit, but this is fine
<LI>No need for machine-level emulation
<LI>Loads executable and each WINE module, performing relocation for API entry
points
<LI>Creates x86 selector for each module segment
<LI>Adds selectors to process LDT with new system call: modify_ldt
<LI>Kernel creates new LDT for process, copies it, and adds new selectors
</LI></UL>
<HR>
<H3>WINE Windows API Emulator</H3>
<UL>
<LI>Loader provides 16-bit entry points for all API functions
<LI>Stack frame is copied on API call and control transfered to 32-bit WINE
function
<LI>WINE code produces X11 calls when appropriate, and captures X events
</LI></UL>
<HR>
<H3>Loadable Kernel Modules</H3><B>Dynamically loaded kernel code</B>
<UL>
<LI>Allows device drivers, file systems, or other routines to be contained in
a module
<LI>Modules can be loaded and unloaded on a running system
<LI>Saves memory and kernel image size; only load those modules you need
<LI>Allows portions of kernel to be maintained and released independently
</LI></UL>
<HR>
<H3>What is a module?</H3>
<UL>
<LI>Simply an object file containing routines and/or data to load into a
running kernel
<LI>If multiple source files are used, prelink into one .o file with ld -r
<LI>Must provide two routines (init_module and cleanup_module) called at
module load/unload </LI></UL><B>Required Tools</B>
<UL>
<LI>A recent 1.2.x or 1.3.x kernel
<LI>Module utilities insmod, lsmod, and rmmod (found with kernel source)
</LI></UL>
<HR>
<H3>Loading a Module</H3>
<OL>
<LI><B>Prepare module in user space</B>
<UL>
<LI>insmod reads object file from disk, resolve any external symbols
<LI>These symbols provided by kernel or other loaded modules using
get_kernel_syms
<LI>This is similar to linking an object against other objects </LI></UL>
<LI><B>Allocate kernel memory</B>
<UL>
<LI>create_module() tells kernel to alloc memory for new module
<LI>Takes two args: name of module and total size </LI></UL>
<LI><B>Load module into kernel memory</B>
<UL>
<LI>init_module() called to copy module into kernel space
<LI>insmod must also pass in module name, size, pointers to init/cleanup,
etc. </LI></UL>
<LI><B>Add exported module symbols to kernel</B>
<UL>
<LI>Symbol table passed in by init_module added to kernel's list
<LI>Module symbols can now be used by other modules --- "stacking"
<LI>Modules can shadow each other's symbols </LI></UL>
<LI><B>Call init_module routine</B>
<UL>
<LI>Module now part of kernel proper; just fire it up </LI></UL></LI></OL>
<HR>
<H3>Module Dependencies and Deletion</H3><B>Deleting a module</B>
<UL>
<LI>Kernel keeps list of module dependencies
<LI>Can't delete a module if any other module uses routines from it
<LI>If ref count is 0, cleanup_module called, and kernel memory freed
</LI></UL><B>Dependencies</B>
<UL>
<LI>Modules can only be loaded into kernel they were compiled under
<LI>This prevents data structures, function interfaces, etc. from differing
<LI>Can cause serious and subtle problems if this is not adhered to!
<LI>New features allow modules to keep track of struct "versions"
<LI>Checksum computed for each data structure used in kernel and module
</LI></UL>
<HR>
<P><I><FONT size=-1>These are slides for the "Linux Frontiers" talk given for
the O'Reilly and Associates "Running Linux '95" tour. For more information
please contact Matt Welsh at <A
href="mailto:mdw@cs.cornell.edu">mdw@cs.cornell.edu</A>. </FONT></I></P>
<P>This file and associated slides are Copyright (c)1995 by Matt Welsh. You are
free to copy and distribute this file (or slides produced thereof) VERBATIM in
any medium, physical or electronic. This copyright notice should be entact on
all copies and attribution to the author retained. </P>
<P>Update: mdw 21 August 1995</P>
<HR>
<P><I><FONT size=-1>Links and conversion from Postscript to HTML done by Matthew
Feldt. </FONT></I></P>
<HR SIZE=4>
<P>Last Modified: 5 September 1995<BR><I>St. Louis Unix Users Group - Linux
SIG</I> </P><!-- END BODY TEXT --></BODY></HTML>

BIN
docs/bin-format/a_out(5) - format of executable binary files.files/p-gsp.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 716 B

277
docs/bin-format/a_out(5) - format of executable binary files.htm Normal file
View File

@@ -0,0 +1,277 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0056)http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=a.out -->
<HTML><HEAD><TITLE>a.out(5) - format of executable binary files</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3502.5390" name=GENERATOR></HEAD>
<BODY aLink=#000000 bgColor=#f3f3ff link=#000099 text=#000000 vLink=#000099>
<H1>a.out(5) - format of executable binary files</H1>
<HR>
<PRE><!-- Manpage converted by man2html 3.0.1 -->
</PRE>
<H2>DESCRIPTION</H2><PRE> The include file &lt;<I>a.out.h</I>&gt; declares three structures and several macros.
The structures describe the format of executable machine code files
(`binaries') on the system.
A binary file consists of up to 7 sections. In order, these sections
are:
exec header Contains parameters used by the kernel to load a binary
file into memory and execute it, and by the link editor
<B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B> to combine a binary file with other binary files.
This section is the only mandatory one.
text segment Contains machine code and related data that are loaded
into memory when a program executes. May be loaded
read-only.
data segment Contains initialized data; always loaded into writable
memory.
text relocations Contains records used by the link editor to update
pointers in the text segment when combining binary
files.
data relocations Like the text relocation section, but for data segment
pointers.
symbol table Contains records used by the link editor to cross ref-
erence the addresses of named variables and functions
(`symbols') between binary files.
string table Contains the character strings corresponding to the
symbol names.
Every binary file begins with an <I>exec</I> structure:
struct exec {
unsigned long a_midmag;
unsigned long a_text;
unsigned long a_data;
unsigned long a_bss;
unsigned long a_syms;
unsigned long a_entry;
unsigned long a_trsize;
unsigned long a_drsize;
};
The fields have the following functions:
<I>a</I><B>_</B><I>midmag</I> This field is stored in host byte-order. It has a number of
sub-components accessed by the macros <B>N_GETFLAG</B>(), <B>N_GETMID</B>(),
which is to be loaded into the process address space by the
run-time link editor.
The macro <B>N_GETMID</B>() returns the machine-id. This indicates
which machine(s) the binary is intended to run on.
<B>N_GETMAGIC</B>() specifies the magic number, which uniquely identi-
fies binary files and distinguishes different loading conven-
tions. The field must contain one of the following values:
OMAGIC The text and data segments immediately follow the
header and are contiguous. The kernel loads both text
and data segments into writable memory.
NMAGIC As with OMAGIC, text and data segments immediately fol-
low the header and are contiguous. However, the kernel
loads the text into read-only memory and loads the data
into writable memory at the next page boundary after
the text.
ZMAGIC The kernel loads individual pages on demand from the
binary. The header, text segment and data segment are
all padded by the link editor to a multiple of the page
size. Pages that the kernel loads from the text seg-
ment are read-only, while pages from the data segment
are writable.
<I>a</I><B>_</B><I>text</I> Contains the size of the text segment in bytes.
<I>a</I><B>_</B><I>data</I> Contains the size of the data segment in bytes.
<I>a</I><B>_</B><I>bss</I> Contains the number of bytes in the `bss segment' and is used
by the kernel to set the initial break (<B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=2&amp;topic=brk">brk(2)</A></B>) after the data
segment. The kernel loads the program so that this amount of
writable memory appears to follow the data segment and ini-
tially reads as zeroes.
<I>a</I><B>_</B><I>syms</I> Contains the size in bytes of the symbol table section.
<I>a</I><B>_</B><I>entry</I> Contains the address in memory of the entry point of the pro-
gram after the kernel has loaded it; the kernel starts the exe-
cution of the program from the machine instruction at this
address.
<I>a</I><B>_</B><I>trsize</I> Contains the size in bytes of the text relocation table.
<I>a</I><B>_</B><I>drsize</I> Contains the size in bytes of the data relocation table.
The <I>a.out.h</I> include file defines several macros which use an <I>exec</I> struc-
ture to test consistency or to locate section offsets in the binary file.
<B>N_BADMAG</B>(<I>exec</I>) Nonzero if the <I>a</I><B>_</B><I>magic</I> field does not contain a recog-
unsigned int r_symbolnum : 24,
r_pcrel : 1,
r_length : 2,
r_extern : 1,
r_baserel : 1,
r_jmptable : 1,
r_relative : 1,
r_copy : 1;
};
The <I>relocation</I><B>_</B><I>info</I> fields are used as follows:
<I>r</I><B>_</B><I>address</I> Contains the byte offset of a pointer that needs to be link-
edited. Text relocation offsets are reckoned from the start
of the text segment, and data relocation offsets from the
start of the data segment. The link editor adds the value
that is already stored at this offset into the new value
that it computes using this relocation record.
<I>r</I><B>_</B><I>symbolnum</I> Contains the ordinal number of a symbol structure in the
symbol table (it is <I>not</I> a byte offset). After the link edi-
tor resolves the absolute address for this symbol, it adds
that address to the pointer that is undergoing relocation.
(If the <I>r</I><B>_</B><I>extern</I> bit is clear, the situation is different;
see below.)
<I>r</I><B>_</B><I>pcrel</I> If this is set, the link editor assumes that it is updating
a pointer that is part of a machine code instruction using
pc-relative addressing. The address of the relocated
pointer is implicitly added to its value when the running
program uses it.
<I>r</I><B>_</B><I>length</I> Contains the log base 2 of the length of the pointer in
bytes; 0 for 1-byte displacements, 1 for 2-byte displace-
ments, 2 for 4-byte displacements.
<I>r</I><B>_</B><I>extern</I> Set if this relocation requires an external reference; the
link editor must use a symbol address to update the pointer.
When the <I>r</I><B>_</B><I>extern</I> bit is clear, the relocation is `local';
the link editor updates the pointer to reflect changes in
the load addresses of the various segments, rather than
changes in the value of a symbol (except when <I>r</I><B>_</B><I>baserel</I> is
also set (see below). In this case, the content of the
<I>r</I><B>_</B><I>symbolnum</I> field is an <I>n</I><B>_</B><I>type</I> value (see below); this type
field tells the link editor what segment the relocated
pointer points into.
<I>r</I><B>_</B><I>baserel</I> If set, the symbol, as identified by the <I>r</I><B>_</B><I>symbolnum</I> field,
is to be relocated to an offset into the Global Offset
Table. At run-time, the entry in the Global Offset Table at
this offset is set to be the address of the symbol.
Since the link-editor adjusts addresses, a symbol's name must be used to
stand for its address until an absolute value has been assigned. Symbols
consist of a fixed-length record in the symbol table and a variable-
length name in the string table. The symbol table is an array of <I>nlist</I>
structures:
struct nlist {
union {
char *n_name;
long n_strx;
} n_un;
unsigned char n_type;
char n_other;
short n_desc;
unsigned long n_value;
};
The fields are used as follows:
<I>n</I><B>_</B><I>un.n</I><B>_</B><I>strx</I> Contains a byte offset into the string table for the name of
this symbol. When a program accesses a symbol table with
the <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=3&amp;topic=nlist">nlist(3)</A></B> function, this field is replaced with the
<I>n</I><B>_</B><I>un.n</I><B>_</B><I>name</I> field, which is a pointer to the string in mem-
ory.
<I>n</I><B>_</B><I>type</I> Used by the link editor to determine how to update the sym-
bol's value. The <I>n</I><B>_</B><I>type</I> field is broken down into three
sub-fields using bitmasks. The link editor treats symbols
with the N_EXT type bit set as `external' symbols and per-
mits references to them from other binary files. The N_TYPE
mask selects bits of interest to the link editor:
N_UNDF An undefined symbol. The link editor must locate an
external symbol with the same name in another binary
file to determine the absolute value of this symbol.
As a special case, if the <I>n</I><B>_</B><I>value</I> field is nonzero
and no binary file in the link-edit defines this
symbol, the link-editor will resolve this symbol to
an address in the bss segment, reserving an amount
of bytes equal to <I>n</I><B>_</B><I>value</I>. If this symbol is unde-
fined in more than one binary file and the binary
files do not agree on the size, the link editor
chooses the greatest size found across all binaries.
N_ABS An absolute symbol. The link editor does not update
an absolute symbol.
N_TEXT A text symbol. This symbol's value is a text
address and the link editor will update it when it
merges binary files.
N_DATA A data symbol; similar to N_TEXT but for data
value is the first text address from that binary
file. Filename symbols are not needed for link-
editing or loading, but are useful for debuggers.
The N_STAB mask selects bits of interest to symbolic debug-
gers such as <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=gdb">gdb(1)</A></B>; the values are described in <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=5&amp;topic=stab">stab(5)</A></B>.
<I>n</I><B>_</B><I>other</I> This field provides information on the nature of the symbol
independent of the symbol's location in terms of segments as
determined by the <I>n</I><B>_</B><I>type</I> field. Currently, the lower 4 bits
of the <I>n</I><B>_</B><I>other</I> field hold one of two values: AUX_FUNC and
AUX_OBJECT (see &lt;<I>link.h</I>&gt; for their definitions). AUX_FUNC
associates the symbol with a callable function, while
AUX_OBJECT associates the symbol with data, irrespective of
their locations in either the text or the data segment.
This field is intended to be used by <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B> for the construc-
tion of dynamic executables.
<I>n</I><B>_</B><I>desc</I> Reserved for use by debuggers; passed untouched by the link
editor. Different debuggers use this field for different
purposes.
<I>n</I><B>_</B><I>value</I> Contains the value of the symbol. For text, data and bss
symbols, this is an address; for other symbols (such as
debugger symbols), the value may be arbitrary.
The string table consists of an <I>unsigned</I> <I>long</I> length followed by null-
terminated symbol strings. The length represents the size of the entire
table in bytes, so its minimum value (or the offset of the first string)
is always 4 on 32-bit machines.
</PRE>
<H2>SEE ALSO</H2><PRE> <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=as">as(1)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=gdb">gdb(1)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=2&amp;topic=brk">brk(2)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=2&amp;topic=execve">execve(2)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=3&amp;topic=nlist">nlist(3)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=5&amp;topic=core">core(5)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=5&amp;topic=elf">elf(5)</A></B>,
<B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=5&amp;topic=link">link(5)</A></B>, <B><A href="http://www.gsp.com/cgi-bin/man.cgi?section=5&amp;topic=stab">stab(5)</A></B>
</PRE>
<H2>HISTORY</H2><PRE> The <I>a.out.h</I> include file appeared in Version 7 AT&amp;T UNIX.
</PRE>
<H2>BUGS</H2><PRE> Since not all of the supported architectures use the <I>a</I><B>_</B><I>midmag</I> field, it
can be difficult to determine what architecture a binary will execute on
without examining its actual machine code. Even with a machine identi-
fier, the byte order of the <I>exec</I> header is machine-dependent.
Nobody seems to agree on what <I>bss</I> stands for.
FreeBSD 4.4 June 5, 1993 FreeBSD 4.4
</PRE>
<HR>
<P><A href="http://www.gsp.com/"><IMG align=right alt="Powered by GSP" border=1
height=31 src="a_out(5) - format of executable binary files.files/p-gsp.gif"
width=88></A> Visit the GSP <A href="http://www.gsp.com/support/man/">FreeBSD
Man Page Interface</A>. <BR>Output converted with <A
href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</A>.
</P></BODY></HTML>

347
docs/bin-format/a_out.htm Normal file
View File

@@ -0,0 +1,347 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0060)http://resin.csoft.net/cgi-bin/man.cgi?section=5&topic=a.out -->
<HTML><HEAD><TITLE>a.out</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3502.5390" name=GENERATOR></HEAD>
<BODY>
<H1>a.out</H1>
<HR>
<PRE><!-- Manpage converted by man2html 3.0.1 -->
<B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=A.OUT">A.OUT(5)</A></B> OpenBSD Programmer's Manual <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=A.OUT">A.OUT(5)</A></B>
</PRE>
<H2>NAME</H2><PRE> <B>a.out</B> - format of executable binary files
</PRE>
<H2>SYNOPSIS</H2><PRE> <B>#include</B> <B>&lt;sys/types.h&gt;</B>
<B>#include</B> <B>&lt;a.out.h&gt;</B>
</PRE>
<H2>DESCRIPTION</H2><PRE> The include file &lt;<I>a.out.h</I>&gt; declares three structures and several macros.
The structures describe the format of executable machine code files
(``binaries'') on the system.
A binary file consists of up to 7 sections. In order, these sections
are:
exec header Contains parameters used by the kernel to load a binary
file into memory and execute it, and by the link editor
<B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B> to combine a binary file with other binary files.
This section is the only mandatory one.
text segment Contains machine code and related data that are loaded
into memory when a program executes. May be loaded
read-only.
data segment Contains initialized data; always loaded into writable
memory.
text relocations Contains records used by the link editor to update
pointers in the text segment when combining binary
files.
data relocations Like the text relocation section, but for data segment
pointers.
symbol table Contains records used by the link editor to cross ref-
erence the addresses of named variables and functions
(``symbols'') between binary files.
string table Contains the character strings corresponding to the
symbol names.
Every binary file begins with an <I>exec</I> structure:
struct exec {
u_int32_t a_midmag;
u_int32_t a_text;
u_int32_t a_data;
u_int32_t a_bss;
u_int32_t a_syms;
u_int32_t a_entry;
u_int32_t a_trsize;
u_int32_t a_drsize;
};
The fields have the following functions:
<I>a</I><B>_</B><I>midmag</I> This field is stored in network byte-order so that binaries for
machines with alternate byte orders can be distinguished. It
has a number of sub-components accessed by the macros
<B>N_GETFLAG</B>(), <B>N_GETMID</B>(), and <B>N_GETMAGIC</B>(), and set by the macro
<B>N_SETMAGIC</B>().
The macro <B>N_GETFLAG</B>() returns a few flags:
EX_DYNAMIC Indicates that the executable requires the services
of the run-time link editor.
EX_PIC Indicates that the object contains position inde-
pendent code. This flag is set by <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=as">as(1)</A></B> when given
the <B>-k</B> flag and is preserved by <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B> if necessary.
If both EX_DYNAMIC and EX_PIC are set, the object file is a po-
sition independent executable image (e.g., a shared library),
which is to be loaded into the process address space by the
run-time link editor.
The macro <B>N_GETMID</B>() returns the machine ID. This indicates
which machine(s) the binary is intended to run on.
<B>N_GETMAGIC</B>() specifies the magic number, which uniquely identi-
fies binary files and distinguishes different loading conven-
tions. The field must contain one of the following values:
OMAGIC The text and data segments immediately follow the head-
er and are contiguous. The kernel loads both text and
data segments into writable memory.
NMAGIC As with OMAGIC, text and data segments immediately fol-
low the header and are contiguous. However, the kernel
loads the text into read-only memory and loads the data
into writable memory at the next page boundary after
the text.
ZMAGIC The kernel loads individual pages on demand from the
binary. The header, text segment and data segment are
all padded by the link editor to a multiple of the page
size. Pages that the kernel loads from the text seg-
ment are read-only, while pages from the data segment
are writable.
<I>a</I><B>_</B><I>text</I> Contains the size of the text segment in bytes.
<I>a</I><B>_</B><I>data</I> Contains the size of the data segment in bytes.
<I>a</I><B>_</B><I>bss</I> Contains the number of bytes in the ``BSS segment'' and is used
by the kernel to set the initial break (<B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=2&amp;topic=brk">brk(2)</A></B>) after the data
segment. The kernel loads the program so that this amount of
writable memory appears to follow the data segment and initial-
ly reads as zeroes.
<I>a</I><B>_</B><I>syms</I> Contains the size in bytes of the symbol table section.
<I>a</I><B>_</B><I>entry</I> Contains the address in memory of the entry point of the pro-
gram after the kernel has loaded it; the kernel starts the exe-
cution of the program from the machine instruction at this ad-
dress.
<I>a</I><B>_</B><I>trsize</I> Contains the size in bytes of the text relocation table.
<I>a</I><B>_</B><I>drsize</I> Contains the size in bytes of the data relocation table.
The <I>a.out.h</I> include file defines several macros which use an <I>exec</I> struc-
ture to test consistency or to locate section offsets in the binary file.
<B>N_BADMAG</B>(<I>exec</I>) Non-zero if the <I>a</I><B>_</B><I>magic</I> field does not contain a recog-
nized value.
<B>N_TXTOFF</B>(<I>exec</I>) The byte offset of the beginning of the text segment.
<B>N_DATOFF</B>(<I>exec</I>) The byte offset of the beginning of the data segment.
<B>N_DRELOFF</B>(<I>exec</I>) The byte offset of the beginning of the data relocation
table.
<B>N_TRELOFF</B>(<I>exec</I>) The byte offset of the beginning of the text relocation
table.
<B>N_SYMOFF</B>(<I>exec</I>) The byte offset of the beginning of the symbol table.
<B>N_STROFF</B>(<I>exec</I>) The byte offset of the beginning of the string table.
Relocation records have a standard format which is described by the
<I>relocation</I><B>_</B><I>info</I> structure:
struct relocation_info {
int r_address;
unsigned int r_symbolnum : 24,
r_pcrel : 1,
r_length : 2,
r_extern : 1,
r_baserel : 1,
r_jmptable : 1,
r_relative : 1,
r_copy : 1;
};
The <I>relocation</I><B>_</B><I>info</I> fields are used as follows:
<I>r</I><B>_</B><I>address</I> Contains the byte offset of a pointer that needs to be link-
edited. Text relocation offsets are reckoned from the start
of the text segment, and data relocation offsets from the
start of the data segment. The link editor adds the value
that is already stored at this offset into the new value
that it computes using this relocation record.
<I>r</I><B>_</B><I>symbolnum</I> Contains the ordinal number of a symbol structure in the
symbol table (it is <I>not</I> a byte offset). After the link edi-
tor resolves the absolute address for this symbol, it adds
that address to the pointer that is undergoing relocation.
(If the <I>r</I><B>_</B><I>extern</I> bit is clear, the situation is different;
see below.)
<I>r</I><B>_</B><I>pcrel</I> If this is set, the link editor assumes that it is updating
a pointer that is part of a machine code instruction using
pc-relative addressing. The address of the relocated point-
er is implicitly added to its value when the running program
uses it.
<I>r</I><B>_</B><I>length</I> Contains the log base 2 of the length of the pointer in
bytes; 0 for 1-byte displacements, 1 for 2-byte displace-
ments, 2 for 4-byte displacements.
<I>r</I><B>_</B><I>extern</I> Set if this relocation requires an external reference; the
link editor must use a symbol address to update the pointer.
When the <I>r</I><B>_</B><I>extern</I> bit is clear, the relocation is ``local'';
the link editor updates the pointer to reflect changes in
the load addresses of the various segments, rather than
changes in the value of a symbol (except when <I>r</I><B>_</B><I>baserel</I> is
also set, see below). In this case, the content of the
<I>r</I><B>_</B><I>symbolnum</I> field is an <I>n</I><B>_</B><I>type</I> value (see below); this type
field tells the link editor what segment the relocated
pointer points into.
<I>r</I><B>_</B><I>baserel</I> If set, the symbol, as identified by the <I>r</I><B>_</B><I>symbolnum</I> field,
is to be relocated to an offset into the Global Offset
Table. At run-time, the entry in the Global Offset Table at
this offset is set to be the address of the symbol.
<I>r</I><B>_</B><I>jmptable</I> If set, the symbol, as identified by the <I>r</I><B>_</B><I>symbolnum</I> field,
is to be relocated to an offset into the Procedure Linkage
Table.
<I>r</I><B>_</B><I>relative</I> If set, this relocation is relative to the (run-time) load
address of the image this object file is going to be a part
of. This type of relocation only occurs in shared objects.
<I>r</I><B>_</B><I>copy</I> If set, this relocation record identifies a symbol whose
contents should be copied to the location given in
<I>r</I><B>_</B><I>address.</I> The copying is done by the run-time link editor
from a suitable data item in a shared object.
Symbols map names to addresses (or more generally, strings to values).
Since the link editor adjusts addresses, a symbol's name must be used to
stand for its address until an absolute value has been assigned. Symbols
consist of a fixed-length record in the symbol table and a variable-
length name in the string table. The symbol table is an array of <I>nlist</I>
structures:
struct nlist {
union {
char *n_name;
long n_strx;
} n_un;
unsigned char n_type;
char n_other;
short n_desc;
unsigned long n_value;
};
The fields are used as follows:
<I>n</I><B>_</B><I>un.n</I><B>_</B><I>strx</I> Contains a byte offset into the string table for the name of
this symbol. When a program accesses a symbol table with
the <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=3&amp;topic=nlist">nlist(3)</A></B> function, this field is replaced with the
<I>n</I><B>_</B><I>un.n</I><B>_</B><I>name</I> field, which is a pointer to the string in memo-
ry.
<I>n</I><B>_</B><I>type</I> Used by the link editor to determine how to update the sym-
bol's value. The <I>n</I><B>_</B><I>type</I> field is broken down into three
sub-fields using bitmasks. The link editor treats symbols
with the N_EXT type bit set as ``external'' symbols and per-
mits references to them from other binary files. The N_TYPE
mask selects bits of interest to the link editor:
N_UNDF An undefined symbol. The link editor must locate an
external symbol with the same name in another binary
file to determine the absolute value of this symbol.
As a special case, if the <I>n</I><B>_</B><I>value</I> field is non-zero
and no binary file in the link-edit defines this
symbol, the link editor will resolve this symbol to
an address in the BSS segment, reserving an amount
of bytes equal to <I>n</I><B>_</B><I>value</I>. If this symbol is unde-
fined in more than one binary file and the binary
files do not agree on the size, the link editor
chooses the greatest size found across all binaries.
N_ABS An absolute symbol. The link editor does not update
an absolute symbol.
N_TEXT A text symbol. This symbol's value is a text ad-
dress and the link editor will update it when it
merges binary files.
N_DATA A data symbol; similar to N_TEXT but for data ad-
dresses. The values for text and data symbols are
not file offsets but addresses; to recover the file
offsets, it is necessary to identify the loaded ad-
dress of the beginning of the corresponding section
and subtract it, then add the offset of the section.
N_BSS A BSS symbol; like text or data symbols but has no
corresponding offset in the binary file.
N_FN A filename symbol. The link editor inserts this
symbol before the other symbols from a binary file
when merging binary files. The name of the symbol
is the filename given to the link editor, and its
value is the first text address from that binary
file. Filename symbols are not needed for link
editing or loading, but are useful for debuggers.
The N_STAB mask selects bits of interest to symbolic debug-
gers such as <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=gdb">gdb(1)</A></B>; the values are described in <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=stab">stab(5)</A></B>.
<I>n</I><B>_</B><I>other</I> This field provides information on the nature of the symbol
independent of the symbol's location in terms of segments as
determined by the <I>n</I><B>_</B><I>type</I> field. Currently, the lower 4 bits
of the <I>n</I><B>_</B><I>other</I> field hold one of two values: AUX_FUNC and
AUX_OBJECT (see &lt;<I>link.h</I>&gt; for their definitions). AUX_FUNC
associates the symbol with a callable function, while
AUX_OBJECT associates the symbol with data, irrespective of
their locations in either the text or the data segment.
This field is intended to be used by <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B> for the construc-
tion of dynamic executables.
<I>n</I><B>_</B><I>desc</I> Reserved for use by debuggers; passed untouched by the link
editor. Different debuggers use this field for different
purposes.
<I>n</I><B>_</B><I>value</I> Contains the value of the symbol. For text, data and BSS
symbols, this is an address; for other symbols (such as de-
bugger symbols), the value may be arbitrary.
The string table consists of an <I>u</I><B>_</B><I>int32</I><B>_</B><I>t</I> length followed by null-termi-
nated symbol strings. The length represents the size of the entire table
in bytes, so its minimum value (or the offset of the first string) is al-
ways 4 on 32-bit machines.
</PRE>
<H2>SEE ALSO</H2><PRE> <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=as">as(1)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=gdb">gdb(1)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=1&amp;topic=ld">ld(1)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=2&amp;topic=brk">brk(2)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=2&amp;topic=execve">execve(2)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=3&amp;topic=nlist">nlist(3)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=core">core(5)</A></B>, <B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=link">link(5)</A></B>,
<B><A href="http://resin.csoft.net/cgi-bin/man.cgi?section=5&amp;topic=stab">stab(5)</A></B>
</PRE>
<H2>HISTORY</H2><PRE> The <I>a.out.h</I> include file appeared in Version 3 AT&amp;T UNIX.
</PRE>
<H2>BUGS</H2><PRE> Nobody seems to agree on what <I>BSS</I> stands for.
New binary file formats may be supported in the future, and they probably
will not be compatible at any level with this ancient format.
OpenBSD 3.1 June 5, 1993 5
</PRE>
<HR>
<ADDRESS>Man(1) output converted with <A
href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</A>
</ADDRESS></BODY></HTML>

BIN
docs/bin-format/sp12.ppt Normal file
View File

Binary file not shown.