path: root/ja/man/man5/a.out.5

.\" Copyright (c) 1991, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" This man page is derived from documentation contributed to Berkeley by
.\" Donn Seeley at UUNET Technologies, Inc.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)a.out.5	8.1 (Berkeley) 6/5/93
.\"	%Id: a.out.5,v 1.7 1997/02/22 13:25:56 peter Exp %
.\"
.\" jpman %Id: a.out.5,v 1.3 1998/08/09 12:51:56 horikawa Stab %
.\" WORD: byte order	バイト順
.\" WORD: posision independent	位置独立(な)
.\" WORD: link editor	リンクエディタ
.\" WORD: link edit	リンクエディット
.\"
.Dd June 5, 1993
.Dt A.OUT 5
.Os
.Sh 名称
.Nm a.out
.Nd 実行可能バイナリファイルのフォーマット
.Sh 書式
.Fd #include <a.out.h>
.Sh 解説
インクルードファイル
.Aq Pa a.out.h
では 3 つの構造体といくつかのマクロが宣言されています。
これらの構造体は、このシステムで実行可能な機械語コードファイル
.Pq Sq バイナリ
のフォーマットを規定します。
.Pp
バイナリファイルは最大で 7 つのセクションから構成されます。
これらのセクションを順にあげると以下のようになります:
.Bl -tag -width "テキストリロケーション"
.It exec ヘッダ
バイナリファイルをメモリ上にロードして実行するために
カーネルが用いるパラメータを含んでいます。
これらのパラメータはリンクエディタ
.Xr ld 1
がバイナリファイルを他のバイナリファイルと結合する際にも
用いられます。
このセクションは唯一の必須セクションです。
.It テキストセグメント
プログラムが実行される際にメモリ上にロードされる
機械語コード及び関連データを含んでいます。
読み込み専用でロードされる場合があります。
.It データセグメント
初期化済データを含んでいます。
常に書き込み可能なメモリ上にロードされます。
.It テキストリロケーション
バイナリファイル結合時にテキストセグメント内のポインタを修正するために、
リンクエディタによって用いられるレコードを含んでいます。
.It データリロケーション
前出のテキストリロケーションセクションと似ていますが、
データセグメント内のポインタ修正用です。
.It シンボルテーブル
バイナリファイル間で
名前付きの変数や関数
.Pq Sq シンボル
のアドレス相互参照を解決するために、
リンクエディタによって用いられるレコードを含んでいます。
.It string table
シンボル名に対応する文字列を含んでいます。
.El
.Pp
全てのバイナリファイルは次の
.Fa exec
構造体で始まります:
.Bd -literal -offset indent
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;
};
.Ed
.Pp
これらのフィールドは以下の機能を持っています:
.Bl -tag -width a_trsize
.It Fa a_midmag
このフィールドはホストのバイト順 (host byte-order) で格納されます。
このフィールドはいくつかのサブコンポーネントを持っており、それらは
以下のマクロ
.Dv N_GETFLAG() ,
.Dv N_GETMID() ,
.Dv N_GETMAGIC()
で参照され、マクロ
.Dv N_SETMAGIC()
で設定されます。
.Pp
マクロ
.Dv N_GETFLAG()
は以下のフラグを返します:
.Bl -tag -width EX_DYNAMIC
.It Dv EX_DYNAMIC
この実行可能ファイルがランタイムリンクエディタのサービスを要求することを
示します。
.It Dv EX_PIC
このオブジェクトファイルが位置独立 (position independent) なコードを
含んでいることを示します。
このフラグは
.Sq -k
フラグ指定時に
.Xr as 1
によって設定され、必要なら
.Xr ld 1
はこれを保存します。
.El
.Pp
EX_DYNAMIC と EX_PIC の両方がセットされている場合、
そのオブジェクトファイルは位置独立な実行可能イメージです (例: 共有ライブラリ)。
これはランタイムリンクエディタによってプロセスのアドレス空間にロードされます。
.Pp
マクロ
.Dv N_GETMID()
はマシン識別コード (machine-id) を返します。
これは、バイナリファイルが実行されるべきマシンを示しています。
.Pp
.Dv N_GETMAGIC()
はマジックナンバを示します。
マジックナンバはバイナリファイル種別を一意に識別し、
様々なロード方法を区別します。
このフィールドは以下の値のいずれか 1 つを含んでいなければなりません:
.Bl -tag -width ZMAGIC
.It Dv OMAGIC
テキストセグメントとデータセグメントはヘッダの直後にあり、
連続しています。
カーネルはテキスト/データセグメントの両方を書き込み可能メモリ領域に
ロードします。
.It Dv NMAGIC
.Dv OMAGIC
と同様、テキスト/データセグメントはヘッダの直後にあり、連続しています。
しかし、カーネルはテキストセグメントを読み込み専用メモリ領域にロードし、
テキストに続くページ境界から始まる
書き込み可能メモリ領域にデータセグメントをロードします。
.It Dv ZMAGIC
カーネルは各々のページを必要に応じてバイナリからロードします。
ヘッダ、テキストセグメント及びデータセグメントはいずれも、
ページサイズの倍数の大きさになるよう、
リンクエディタによってパディングされます。
カーネルがテキストセグメントからロードしたページは読み込み専用ですが、
データセグメントからロードしたページは書き込み可能です。
.El
.It Fa a_text
テキストセグメントのサイズ (バイト単位) を保持します。
.It Fa a_data
データセグメントのサイズ (バイト単位) を保持します。
.It Fa a_bss
.Sq bss セグメント
のバイト数を保持します。
この値はカーネルが最初の break 値
.Pq Xr brk 2
をデータセグメントの後ろに設定するのに用いられます。
カーネルは、ここに示されるサイズの書き込み可能メモリ領域が
データセグメントの後ろに用意され、それらの初期状態が 0 になるように、
プログラムをロードします。
.It Fa a_syms
シンボルテーブルセクションのサイズ (バイト単位) を保持します。
.It Fa a_entry
カーネルがバイナリファイルをロードした後の、
プログラムのエントリポイントのメモリアドレスを保持します。
カーネルは、このアドレスにある機械命令からプログラムの実行を開始します。
.It Fa a_trsize
テキストリロケーションテーブルのサイズ (バイト単位) を保持します。
.It Fa a_drsize
データリロケーションテーブルのサイズ (バイト単位) を保持します。
.El
.Pp
インクルードファイル
.Pa a.out.h
では、
.Fa exec
構造体を用いて一貫性をテストしたりバイナリファイル中のセクションオフセットを
知るためのマクロが定義されています。
.Bl -tag -width N_BADMAG(exec)
.It Fn N_BADMAG exec
.Fa a_magic
フィールドに、認識できない値が含まれている場合、非 0 を返します。
.It Fn N_TXTOFF exec
バイナリファイルにおけるテキストセグメントの先頭のバイトオフセットを返します。
.It Fn N_SYMOFF exec
シンボルテーブルの先頭のバイトオフセットを返します。
.It Fn N_STROFF exec
文字列テーブルの先頭のバイトオフセットを返します。
.El
.Pp
リロケーションレコードは、
.Fa relocation_info
構造体で規定される標準フォーマットです:
.Bd -literal -offset indent
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;
};
.Ed
.Pp
.Fa relocation_info
構造体の各フィールドは以下のように用いられます:
.Bl -tag -width r_symbolnum
.It Fa r_address
リンクエディットが必要なポインタのバイトオフセットを保持します。
テキストリロケーションオフセットはテキストセグメントの先頭から、
データリロケーションオフセットはデータセグメントの先頭から、
それぞれ計算します。
リンクエディタはこのオフセットにストアされている値を加算し、
このリロケーションレコードを用いて計算した新しい値に変換します。
.It Fa r_symbolnum
シンボルテーブルにおけるシンボル構造体の順序番号 (
バイトオフセット
.Em ではありません
) を保持します。
リンクエディタはこのシンボルの絶対アドレスを解決した後、
そのアドレスをリロケーション中のポインタに加算します。
(もし
.Fa r_extern
ビットが立っていなければ状況は異なります。以下を参照して下さい。)
.It Fa r_pcrel
もしこのビットが立っていれば、
リンクエディタは、PC 相対アドレシングを用いる機械語命令の一部である
ポインタを更新しているものと仮定します。
リロケートされるポインタのアドレスは、実行中のプログラムがそれを用いる際に、
暗黙的にその値に加算されます。
.It Fa r_length
ポインタの長さを 2 を底とする対数で表したバイト単位で保持します。
1 バイトディスプレースメントなら 0、
2 バイトディスプレースメントなら 1、
4 バイトディスプレースメントなら 2 となります。
.It Fa r_extern
このリロケーションが外部参照を必要としている場合にセットされます。
リンクエディタは、シンボルアドレスを用いてこのポインタを
更新しなければなりません。
.Fa r_extern
ビットが立っていない場合、そのリロケーションは
.Sq ローカル
です。
リンクエディタは、シンボル値の変化ではなく、
各セグメントのロードアドレスの変化に応じてポインタを更新します
(ただし、
.Fa r_baserel
もセットされている場合(後述)は除きます)。
この場合、
.Fa r_symbolnum
フィールドの内容は
.Fa n_type
の値となります(後述)。
リンクエディタは、この型フィールドから、
リロケートされるポインタがどのセグメントを指しているのかの情報を得ます。
.It Fa r_baserel
セットされている場合、
.Fa r_symbolnum
フィールドで指定される場合のように、
このシンボルはグローバルオフセットテーブルへのオフセットに
リロケートされます。
実行時に、グローバルオフセットテーブル中の、このオフセット位置にある
エントリが、シンボルのアドレスを持つようにセットされます。
.It Fa r_jmptable
セットされている場合、
.Fa r_symbolnum
フィールドで指定される場合のように、
このシンボルはプロシージャリンケージテーブルへのオフセットに
リロケートされます。
.It Fa r_relative
セットされている場合、
このリロケーションは、このオブジェクトファイルが含まれる
イメージの (実行時の) ロードアドレスとの相対値となります。
この種のリロケーションは共有オブジェクトにのみ現れます。
.It Fa r_copy
セットされている場合、
このリロケーションレコードは、
その内容を
.Fa r_address
で指定される位置にコピーしなければならないシンボルを示します。
コピー処理は、実行時のリンクエディタによって、
共有オブジェクト中の適切なデータアイテムから行われます。
.El
.Pp
シンボルは名前とアドレスを対応づけます (より一般的には、
文字列を値へ対応づけます)。
リンクエディタがアドレスを調節するため、
絶対値が割り当てられるまではシンボルを用いてアドレスを表現しなければ
なりません。
シンボルは、シンボルテーブル中の固定長のレコードと、
文字列テーブル中の可変長の名前から成ります。
シンボルテーブルは
.Fa nlist
構造体の配列です:
.Bd -literal -offset indent
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;
};
.Ed
.Pp
これらのフィールドは以下のように用いられます:
.Bl -tag -width n_un.n_strx
.It Fa n_un.n_strx
このシンボルの名前の、文字列テーブルでのバイトオフセットを保持します。
プログラムが
.Xr nlist 3
関数を用いてシンボルテーブルをアクセスする場合、
このフィールドは、
メモリ中の文字列へのポインタである
.Fa n_un.n_name
フィールドに置き換えられます。
.It Fa n_type
リンクエディタがシンボル値の更新方法を決定するのに用いられます。
.Fa n_type
フィールドは、ビットマスクを用いた 3 つのサブフィールドに分けられます。
リンクエディタは
.Dv N_EXT
ビットがセットされているシンボルを
.Sq external
シンボルとして扱い、他のバイナリファイルからの参照を許可します。
.Dv N_TYPE
マスクはリンクエディタに必要なビットを選択します:
.Bl -tag -width N_TEXT
.It Dv N_UNDF
未定義シンボル。
リンクエディタは、他のバイナリファイル中の同じ名前の外部シンボルを探して
このシンボルの絶対値を決定しなければなりません。
特別な場合として、もし
.Fa n_value
フィールドが非 0 で、リンクエディット対象のどのバイナリファイルも
このシンボルを定義していない場合、
リンクエディタはこのシンボルが bss セグメント中のアドレスであるとみなし、
.Fa n_value
に等しいバイト数の領域を予約します。
もしこのシンボルが複数のバイナリファイル中で未定義となっており、
それらのバイナリファイル間でサイズが異なっている場合、
リンクエディタはそれらのサイズの最大値を選びます。
.It Dv N_ABS
絶対シンボル。
リンクエディタは絶対シンボルは更新しません。
.It Dv N_TEXT
テキストシンボル。
このシンボルの値はテキストアドレスであり、
リンクエディタはバイナリファイルをマージする際、その値を更新します。
.It Dv N_DATA
データシンボル。
.Dv N_TEXT
と同様ですが、データアドレスを表します。
テキストシンボル及びデータシンボルの値は、
ファイルオフセットではなくアドレスです。
ファイルオフセットを復元するために、
対応するセクションの先頭のロードアドレスを見つけてそれを減じ、
次にそのセクションのオフセットを加算する必要があります。
.It Dv N_BSS
bss シンボル。テキストシンボルやデータシンボルと似ていますが、
バイナリファイル中に対応するオフセットを持ちません。
.It Dv N_FN
ファイル名シンボル。
バイナリファイルをマージする際、
リンクエディタはバイナリファイルの他のシンボルの前にこのシンボルを
挿入します。
このシンボルの名前はリンクエディタに与えられたファイル名で、
シンボルの値はバイナリファイルから得た先頭テキストアドレスです。
ファイル名シンボルはリンクエディト処理やロード処理には不要ですが、
デバッガには有用な情報です。
.El
.Pp
.Dv N_STAB
マスクは
.Xr gdb 1
等のシンボリックデバッガに必要なビットを選択します。
その値は
.Xr stab 5
に示されています。
.It Fa n_other
このフィールドは、
.Fa n_type
フィールドで決定されるセグメントに関して、
そのシンボルのロケーションとは独立した
シンボルの特質に関する情報を提供します。
現在のところ、
.Fa n_other
フィールドの下位 4 ビットは
.Dv AUX_FUNC
あるいは
.Dv AUX_OBJECT
のいずれかをとります
.Po
これらの定義については
.Aq Pa link.h
を参照してください
.Pc 。
.Dv AUX_FUNC
はシンボルと呼び出し可能な関数を関連づけ、他方、
.Dv AUX_OBJECT
はシンボルとデータを関連づけます。
これらの関連はテキストセグメント/データセグメントの別とは無関係です。
このフィールドは、
.Xr ld 1
が動的な実行可能形式を構築するために使うことを意図しています。
.It Fa n_desc
デバッガ用に予約されており、リンクエディタはこのフィールドを全く変更しません。
デバッガによって異なった目的に使われます。
.It Fa n_value
シンボルの値を保持します。
テキスト, データおよび bss シンボルの場合、その値はアドレスです。
他のシンボル (例えばデバッガシンボル等) の場合、その値は様々です。
.El
.Pp
文字列テーブルは
.Em unsigned long
型の長さと、それに続くナル終端のシンボル文字列から成ります。
この長さは、テーブル全体のサイズをバイト単位で表します。
つまり、その最小値 (言い替えれば、最初の文字列のオフセット) は、
32 ビットマシンでは常に 4 となります。
.Sh 関連項目
.Xr as 1 ,
.Xr gdb 1 ,
.Xr ld 1 ,
.Xr brk 2 ,
.Xr execve 2 ,
.Xr nlist 3 ,
.Xr core 5 ,
.Xr link 5 ,
.Xr stab 5
.Sh 歴史
インクルードファイル
.Pa a.out.h
は
.At v7
で登場しました。
.Sh バグ
必ずしも全てのサポート対象アーキテクチャが
.Fa a_midmag
フィールドを用いるわけではないので、
あるバイナリがどのようなアーキテクチャ上で実行されるのかは、
実際のマシンコードを調べない限り判定困難な可能性があります。
マシン ID があったとしても、
.Fa exec
ヘッダのバイト順はマシン依存です。
.Pp
.Em bss
が何の略なのか、に関する合意はないようです。
.Pp
将来、新しいバイナリファイルフォーマットがサポートされるかも知れませんが、
その新フォーマットは恐らく、
あらゆるレベルでこの太古のフォーマットと互換性がないでしょう。