A.OUT(5) Formats de fichiers de FreeBSD
NOM
a.out - format de fichiers binaires exécutables
SYNOPSIS
#include <a.out.h>
DESCRIPTION
Le fichier inclus <a.out.h> déclare trois structures et quelques macros. Les structures décrivent le format des fichiers de code machine (des "binaires") exécutables sur le système. Un fichier binaire se décompose jusqu'à sept sections. Elles sont, dans l'ordre : Entête exec Contient les paramètres utilisés par le noyau pour charger le fichier binaire en mémoire et l'exécuter et par l'éditeur de liens ld(1) pour combiner un fichier binaire à d'autres fichiers binaires. Cette section est la seule obligatoire. Segment texte Contient le code machine et les données associées chargés en mémoire quand le programme s'exécute. Peut être chargé en lecture seule. Segment de données Contient les données initialisées. Toujours chargé en mémoire inscriptible. Relocalisations de texte Contient les enregistrements utilisés par l'éditeur de liens pour mettre à jour les pointeurs du segment texte lors de la combinaison de fichiers binaires. Relocalisations de données Comme pour la relocalisation de texte mais pour les pointeurs de données. Table des symboles Contient les enregistrements, utilisés par l'éditeur de liens, des références croisées des variables et des fonctions ("symboles") entre les fichiers binaires. Table de chaines Contient les chaines de caractères correspondand aux noms des symboles. Tout fichier binaire commence par une structure exec :
Le fichier inclus <a.out.h> déclare trois structures et quelques macros. Les structures décrivent le format des fichiers de code machine (des "binaires") exécutables sur le système.
Un fichier binaire se décompose jusqu'à sept sections. Elles sont, dans l'ordre :
Entête exec
Contient les paramètres utilisés par le noyau pour charger le fichier binaire en mémoire et l'exécuter et par l'éditeur de liens ld(1) pour combiner un fichier binaire à d'autres fichiers binaires. Cette section est la seule obligatoire.
Segment texte
Contient le code machine et les données associées chargés en mémoire quand le programme s'exécute. Peut être chargé en lecture seule.
Segment de données
Contient les données initialisées. Toujours chargé en mémoire inscriptible.
Relocalisations de texte
Contient les enregistrements utilisés par l'éditeur de liens pour mettre à jour les pointeurs du segment texte lors de la combinaison de fichiers binaires.
Relocalisations de données
Comme pour la relocalisation de texte mais pour les pointeurs de données.
Table des symboles
Contient les enregistrements, utilisés par l'éditeur de liens, des références croisées des variables et des fonctions ("symboles") entre les fichiers binaires.
Table de chaines
Contient les chaines de caractères correspondand aux noms des symboles.
Tout fichier binaire commence par une structure exec :
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; };
Les champs ont les fonctions suivantes : a_midmag Ce champs est stocké dans l'ordre d'octet (byte order) de la machine hôte. Il a un certain nombre de sous-composants accessibles par les macros N_GETFLAG(), N_GETMID() et N_GETMAGIC() et sa valeur est définie par N_SETMAGIC(). La macro N_GETFLAG() renvoie quelques flags : EX_DYNAMIC indique que l'exécutable nécessite les services d'un éditeur de liens au cours de l'exéution. EX_PIC indique que l'objet contient du code indépendant. Ce flag est mis par as(1) lorsque "-k" est donné et est préservé par ld(1) si nécessaire. Si EX_DYNAMIC et EX_PIC sont tout deux définis, le fichier objet est une image exécutable indépendante (par exemple une bibliothèque partagée), chargée dans l'espace d'adressage du process par l'éditeur de liens au cours de l'exéution. La macro N_GETMID() retourne l'identifiant machine. Il indique les machines sur lesquels le binaire est desiné à tourner. N_GETMAGIC() spécifie le nombre magique qui identifie un binaire de façon unique et distingue les différentes conventions de chargement. Ce champ doit contenir une des options suivantes : OMAGIC. Les segments texte et données suivent immédiatement l'entête et sont contiguës. Le noyau charge les deux segments en mémoire inscriptible. NMAGIC. Comme avec OMAGIC, les sections texte et données suivent immédiatement l'entête et sont contiguës. Cependant, le noyau charge le texte en lecture seule et les données en mémoire inscriptible à la première limite de page suivant le texte. ZMAGIC. Le noyau charge les pages individuelles depuis le bianire, à la demande. L'entête, la section texte et la section de données sont complètées par l'éditeur de liens à un multiple de la taille de page. Les pages que le noyau charge depuis la section texte sont en lecture seule et celles de la section de données sont inscriptibles. a_text Contient la taille du segment texte en octets. a_data Contient la taille du segment de données en octets. a_bss Contient le nombre d'octets du "segment bss" et est utilisé par le noyau pour définir la rupture initiale (brk(2)) après le segment de données. Le noyau charge le programme de manière à ce que la quantité de mémoire inscriptible apparaisse comme suivant le segment de données et est initialisée par des zéros. a_syms Contient la taille en octets de la table des symboles. a_entry Contient l'adresse en mémoire du point d'entrée du programme une fois que le noyau l'a chargé. Le noyau commence l'exécution à cette adresse. a_trsize Contient la taille en octets de la section de relocalisations de texte. a_drsize Contient la taille en octets de la section de relocalisations de données. Le fichier inclus a.out.h définit plusieurs macros qui utilisent une structure exec pour tester la consistance ou pour localiser une section dans le fichier binaire. N_BADMAG(exec) Renvoie une valeur différente de zéro si a_magic n'a pas une valeur reconnue. N_TXTOFF(exec) La position en octets du début du segment texte. N_SYMOFF(exec) La position en octets du début de la table des symboles. N_STROFF(exec) La position en octets du début de la table de chaines. Les enregistrements de relocalisation ont un format standard décrit par la structure relocation_info :
Les champs ont les fonctions suivantes :
a_midmag
Ce champs est stocké dans l'ordre d'octet (byte order) de la machine hôte. Il a un certain nombre de sous-composants accessibles par les macros N_GETFLAG(), N_GETMID() et N_GETMAGIC() et sa valeur est définie par N_SETMAGIC(). La macro N_GETFLAG() renvoie quelques flags : EX_DYNAMIC indique que l'exécutable nécessite les services d'un éditeur de liens au cours de l'exéution. EX_PIC indique que l'objet contient du code indépendant. Ce flag est mis par as(1) lorsque "-k" est donné et est préservé par ld(1) si nécessaire. Si EX_DYNAMIC et EX_PIC sont tout deux définis, le fichier objet est une image exécutable indépendante (par exemple une bibliothèque partagée), chargée dans l'espace d'adressage du process par l'éditeur de liens au cours de l'exéution. La macro N_GETMID() retourne l'identifiant machine. Il indique les machines sur lesquels le binaire est desiné à tourner. N_GETMAGIC() spécifie le nombre magique qui identifie un binaire de façon unique et distingue les différentes conventions de chargement. Ce champ doit contenir une des options suivantes : OMAGIC. Les segments texte et données suivent immédiatement l'entête et sont contiguës. Le noyau charge les deux segments en mémoire inscriptible. NMAGIC. Comme avec OMAGIC, les sections texte et données suivent immédiatement l'entête et sont contiguës. Cependant, le noyau charge le texte en lecture seule et les données en mémoire inscriptible à la première limite de page suivant le texte. ZMAGIC. Le noyau charge les pages individuelles depuis le bianire, à la demande. L'entête, la section texte et la section de données sont complètées par l'éditeur de liens à un multiple de la taille de page. Les pages que le noyau charge depuis la section texte sont en lecture seule et celles de la section de données sont inscriptibles.
Ce champs est stocké dans l'ordre d'octet (byte order) de la machine hôte. Il a un certain nombre de sous-composants accessibles par les macros N_GETFLAG(), N_GETMID() et N_GETMAGIC() et sa valeur est définie par N_SETMAGIC().
La macro N_GETFLAG() renvoie quelques flags :
EX_DYNAMIC indique que l'exécutable nécessite les services d'un éditeur de liens au cours de l'exéution.
EX_PIC indique que l'objet contient du code indépendant. Ce flag est mis par as(1) lorsque "-k" est donné et est préservé par ld(1) si nécessaire.
Si EX_DYNAMIC et EX_PIC sont tout deux définis, le fichier objet est une image exécutable indépendante (par exemple une bibliothèque partagée), chargée dans l'espace d'adressage du process par l'éditeur de liens au cours de l'exéution.
La macro N_GETMID() retourne l'identifiant machine. Il indique les machines sur lesquels le binaire est desiné à tourner.
N_GETMAGIC() spécifie le nombre magique qui identifie un binaire de façon unique et distingue les différentes conventions de chargement. Ce champ doit contenir une des options suivantes :
OMAGIC. Les segments texte et données suivent immédiatement l'entête et sont contiguës. Le noyau charge les deux segments en mémoire inscriptible. NMAGIC. Comme avec OMAGIC, les sections texte et données suivent immédiatement l'entête et sont contiguës. Cependant, le noyau charge le texte en lecture seule et les données en mémoire inscriptible à la première limite de page suivant le texte. ZMAGIC. Le noyau charge les pages individuelles depuis le bianire, à la demande. L'entête, la section texte et la section de données sont complètées par l'éditeur de liens à un multiple de la taille de page. Les pages que le noyau charge depuis la section texte sont en lecture seule et celles de la section de données sont inscriptibles.
OMAGIC. Les segments texte et données suivent immédiatement l'entête et sont contiguës. Le noyau charge les deux segments en mémoire inscriptible.
NMAGIC. Comme avec OMAGIC, les sections texte et données suivent immédiatement l'entête et sont contiguës. Cependant, le noyau charge le texte en lecture seule et les données en mémoire inscriptible à la première limite de page suivant le texte.
ZMAGIC. Le noyau charge les pages individuelles depuis le bianire, à la demande. L'entête, la section texte et la section de données sont complètées par l'éditeur de liens à un multiple de la taille de page. Les pages que le noyau charge depuis la section texte sont en lecture seule et celles de la section de données sont inscriptibles.
a_text
Contient la taille du segment texte en octets.
a_data
Contient la taille du segment de données en octets.
a_bss
Contient le nombre d'octets du "segment bss" et est utilisé par le noyau pour définir la rupture initiale (brk(2)) après le segment de données. Le noyau charge le programme de manière à ce que la quantité de mémoire inscriptible apparaisse comme suivant le segment de données et est initialisée par des zéros.
a_syms
Contient la taille en octets de la table des symboles.
a_entry
Contient l'adresse en mémoire du point d'entrée du programme une fois que le noyau l'a chargé. Le noyau commence l'exécution à cette adresse.
a_trsize
Contient la taille en octets de la section de relocalisations de texte.
a_drsize
Contient la taille en octets de la section de relocalisations de données.
Le fichier inclus a.out.h définit plusieurs macros qui utilisent une structure exec pour tester la consistance ou pour localiser une section dans le fichier binaire.
N_BADMAG(exec)
Renvoie une valeur différente de zéro si a_magic n'a pas une valeur reconnue.
N_TXTOFF(exec)
La position en octets du début du segment texte.
N_SYMOFF(exec)
La position en octets du début de la table des symboles.
N_STROFF(exec)
La position en octets du début de la table de chaines.
Les enregistrements de relocalisation ont un format standard décrit par la structure relocation_info :
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; };
Les champs de relocation_info sont utilisés de la manière suivante : r_address Contient la position en octets d'un pointeur utile à l'éditeur de liens. Les positions des relocalisations de texte sont calculées à partir du début du segment texte et celles de données à partir du début du segment de données. L'éditeur de lien ajoute la valeur déja enregistrée à la nouvelle valeur calculée à partir de l'enregistrement de relocalisation. r_symbolnum Contient un nombre ordinal d'une structure de symboles dans la table des symboles (ce n'est pas une position en octets). Une fois que l'éditeur de lien a trouvé l'adresse absolue du symbole, il ajoute cette adresse au pointeur qui subit la relocalisation. Si le bit r_extern n'est pas mis, la situation est différente, voir plus loin. r_pcrel S'il est défini, l'éditeur de liens considère qu'il met à jour un poiteur qui fait partie des instructions machine utilisant l'adressage pc-relatif. L'adresse du pointeur de relocalisation est implicitemant ajoutée à sa valeur lorsque le programme l'utilise. r_length Contient l'enregistrement en base 2 de la logueur du pointeur en octets. 0 pour un octet, 1 pour 2 octets, 2 pour 4 octets. r_extern Défini si cette relocalisation nécessite une référence externe. L'éditeur de liens doit utiliser l'adresse d'un symbole pour mettre le pointeur à jour. Lorsque le bit r_extern est à 0, la relocalisation est "locale", l'éditeur de liens met le pointeur à jour pour prendre en compte les changements d'adresses des divers segments au lieu des changements de valeur d'un symbole (sauf si r_baserel est aussi défini, voir plus loin). Dans ce cas, le contenu du champ r_symbolnum est une valeur n_type (voir plus loin). Ce type de champs indique à l'éditeur de liens vers quel segment pointe le pointeur de relocalisation. r_baserel Si défini, le symbole, tel qu'il est identifié par le champ r_symbolnum, est à relocaliser à une position de la Global Offset Table. Lors de l'exécution, l'entrée de cette table à cette position est définie comme étant l'adresse du symbole. r_jmptable Si défini, le symbole , tel qu'il est identifié par le champ r_symbolnum, est à relocaliser à une position de la Procedure Linkage Table. r_relative Si défini, cette relocalisation est relative à l'adresse de chargement de l'image dont ce fichier objet va faire partie. Ce type de relocalisation n'apparait que dans les cas d'objets partagés. r_copy Si défini, cet enregistrement de relocalisation identifie un symbol dont le contenu est à copier à la localisation donnée par r_address. La copie est effectuée par l'éditeur de liens à l'exécution depuis l'élément de données en question dans un objet partagé. Les symboles font correspondre des noms à des adresses (ou, plus généralement, des chaines à des valeurs). Puisque l'éditeur de liens ajuste les adresses, un nom de symbole doit remplacer son adresse tant qu'une valeur absolue n'a pas été assignée. Les symboles sont des enregistrements de taille fixe dans la table des symboles et des noms de taille variable dans la table de chaines. La table des symboles est une suite de structures nlist :
Les champs de relocation_info sont utilisés de la manière suivante :
r_address
Contient la position en octets d'un pointeur utile à l'éditeur de liens. Les positions des relocalisations de texte sont calculées à partir du début du segment texte et celles de données à partir du début du segment de données. L'éditeur de lien ajoute la valeur déja enregistrée à la nouvelle valeur calculée à partir de l'enregistrement de relocalisation.
r_symbolnum
Contient un nombre ordinal d'une structure de symboles dans la table des symboles (ce n'est pas une position en octets). Une fois que l'éditeur de lien a trouvé l'adresse absolue du symbole, il ajoute cette adresse au pointeur qui subit la relocalisation. Si le bit r_extern n'est pas mis, la situation est différente, voir plus loin.
r_pcrel
S'il est défini, l'éditeur de liens considère qu'il met à jour un poiteur qui fait partie des instructions machine utilisant l'adressage pc-relatif. L'adresse du pointeur de relocalisation est implicitemant ajoutée à sa valeur lorsque le programme l'utilise.
r_length
Contient l'enregistrement en base 2 de la logueur du pointeur en octets. 0 pour un octet, 1 pour 2 octets, 2 pour 4 octets.
r_extern
Défini si cette relocalisation nécessite une référence externe. L'éditeur de liens doit utiliser l'adresse d'un symbole pour mettre le pointeur à jour. Lorsque le bit r_extern est à 0, la relocalisation est "locale", l'éditeur de liens met le pointeur à jour pour prendre en compte les changements d'adresses des divers segments au lieu des changements de valeur d'un symbole (sauf si r_baserel est aussi défini, voir plus loin). Dans ce cas, le contenu du champ r_symbolnum est une valeur n_type (voir plus loin). Ce type de champs indique à l'éditeur de liens vers quel segment pointe le pointeur de relocalisation.
r_baserel
Si défini, le symbole, tel qu'il est identifié par le champ r_symbolnum, est à relocaliser à une position de la Global Offset Table. Lors de l'exécution, l'entrée de cette table à cette position est définie comme étant l'adresse du symbole.
r_jmptable
Si défini, le symbole , tel qu'il est identifié par le champ r_symbolnum, est à relocaliser à une position de la Procedure Linkage Table.
r_relative
Si défini, cette relocalisation est relative à l'adresse de chargement de l'image dont ce fichier objet va faire partie. Ce type de relocalisation n'apparait que dans les cas d'objets partagés.
r_copy
Si défini, cet enregistrement de relocalisation identifie un symbol dont le contenu est à copier à la localisation donnée par r_address. La copie est effectuée par l'éditeur de liens à l'exécution depuis l'élément de données en question dans un objet partagé.
Les symboles font correspondre des noms à des adresses (ou, plus généralement, des chaines à des valeurs). Puisque l'éditeur de liens ajuste les adresses, un nom de symbole doit remplacer son adresse tant qu'une valeur absolue n'a pas été assignée. Les symboles sont des enregistrements de taille fixe dans la table des symboles et des noms de taille variable dans la table de chaines. La table des symboles est une suite de structures nlist :
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; };
Les champs sont utilisés de la manière suivante : n_un.n_strx Contient la position en octets du nom de ce symbole dans la table des chaines. Lorsqu'un programme accède à la table des symboles avec la fonction nlist(3), ce champs est remplacé par n_un.n_name, le pointeur de la chaine en mémoire. n_type Utilisé par l'éditeur de lien pour savoir comment mettre à jour la valeur du symbole. Le champ n_type est divisé en trois sous-champs par un masque de bits. L'éditeur de liens traite les symboles dont le bit N_EXT est positionné comme un symbole "externe" et permet de les référencer depuis un autre fichier binaire. Le masque N_TYPE définit les bits intéressant l'éditeur de liens : N_UNDF Un symbole indéfini. L'éditeur de liens doit localiser un symbole externe du même nom dans un autre fichier binaire afin d'en déterminer sa valeur absolue. Dans un cas spécial, si le champ n_value est non-zéro et qu'aucun fichier binaire ne définie ce symbole, l'éditeur de lien remplace le par une adresse du segment bss, réservant un nombre d'octet égal à n_value. Si ce symbole est indéfini dans plusieurs fichiers binaires et que ceux-ci ne sont pas d'accord sur la taille, l'éditeur de liens choisi la plus grande trouvée. N_ABS Un symbole absolu. L'éditeur de liens ne modifie pas un symbole absolu. N_TEXT Un symbole texte. La valeur de ce symbole est une adresse de texte et l'éditeur de liens la modifera lorsqu'il fusionnera les ficheirs binaires. N_DATA Un symbole de données. Similaire à N_TEXT mais pour les adresses de données. Les valeurs des symboles de texte et de données ne sont pas des positions mais des adresses. Pour retrouver une position dans un fichier, il faut trouver l'adresse de chargement du début de la section correspondante, la récupérer et l'ajouter à la position de la section. N_BSS Un symbole bss. Comme les symboles de texte et de données mais n'a pas de position correspondante dans le fichier binaire. N_FN Un symbole nom de fichier. L'éditeur de liens place ce symbole avant les autres lorsqu'il fusionne des fichiers binaires. Le nom du symbole est le nom de fichier donné à l'éditeur de liens et sa valeur est la première adresse de texte de ce fichier binaire. Les symboles nom de fichiers ne sont pas utiles à l'édition de liens ou au chargement mais le sont pour le débogage. Le masque N_STAB définit les bits intéressant les débogeurs symboliques tels que gdb(1). Les valeurs sont décrites dans stab(5). n_other Ce champ fournit des informations sur la nature du symbole indépendament de sa localisation dans le segment, comme déterminé par le champ n_type. Actuellement, les quatre bits de poids faible du champ n_other prennent une des deux valeurs AUX_FUNC ou AUX_OBJECT (voir <link.h> pour leur définitions). AUX_FUNC associe le symbole à une fonction appelable et AUX_OBJECT à des données, indépendament de leur localisation dans le segment texte ou données. Ce champ est destiné à être utilisé par ld(1) pour la construction d'exécutables dynamiques. n_desc Réservé aux débogueurs. L'éditeur de liens n'y touche pas. Les divers débogueurs l'utilisent dans différents buts. n_value Contient la valeur du symbole. Pour ceux de type texte, données et bss, il s'agit d'une adresse. Pour les autres (comme ceux de débogage), la valeur est arbitraire. La table des chaines est une longueur de unsigned long suivie de chaines terminées par le symbole null. La longueur représente la taille en octets de la table complète donc sa valeur minimale (ou la position de la première chaine) est toujours 4 sur les machines 32 bits.
Les champs sont utilisés de la manière suivante :
n_un.n_strx
Contient la position en octets du nom de ce symbole dans la table des chaines. Lorsqu'un programme accède à la table des symboles avec la fonction nlist(3), ce champs est remplacé par n_un.n_name, le pointeur de la chaine en mémoire.
n_type
Utilisé par l'éditeur de lien pour savoir comment mettre à jour la valeur du symbole. Le champ n_type est divisé en trois sous-champs par un masque de bits. L'éditeur de liens traite les symboles dont le bit N_EXT est positionné comme un symbole "externe" et permet de les référencer depuis un autre fichier binaire. Le masque N_TYPE définit les bits intéressant l'éditeur de liens : N_UNDF Un symbole indéfini. L'éditeur de liens doit localiser un symbole externe du même nom dans un autre fichier binaire afin d'en déterminer sa valeur absolue. Dans un cas spécial, si le champ n_value est non-zéro et qu'aucun fichier binaire ne définie ce symbole, l'éditeur de lien remplace le par une adresse du segment bss, réservant un nombre d'octet égal à n_value. Si ce symbole est indéfini dans plusieurs fichiers binaires et que ceux-ci ne sont pas d'accord sur la taille, l'éditeur de liens choisi la plus grande trouvée. N_ABS Un symbole absolu. L'éditeur de liens ne modifie pas un symbole absolu. N_TEXT Un symbole texte. La valeur de ce symbole est une adresse de texte et l'éditeur de liens la modifera lorsqu'il fusionnera les ficheirs binaires. N_DATA Un symbole de données. Similaire à N_TEXT mais pour les adresses de données. Les valeurs des symboles de texte et de données ne sont pas des positions mais des adresses. Pour retrouver une position dans un fichier, il faut trouver l'adresse de chargement du début de la section correspondante, la récupérer et l'ajouter à la position de la section. N_BSS Un symbole bss. Comme les symboles de texte et de données mais n'a pas de position correspondante dans le fichier binaire. N_FN Un symbole nom de fichier. L'éditeur de liens place ce symbole avant les autres lorsqu'il fusionne des fichiers binaires. Le nom du symbole est le nom de fichier donné à l'éditeur de liens et sa valeur est la première adresse de texte de ce fichier binaire. Les symboles nom de fichiers ne sont pas utiles à l'édition de liens ou au chargement mais le sont pour le débogage. Le masque N_STAB définit les bits intéressant les débogeurs symboliques tels que gdb(1). Les valeurs sont décrites dans stab(5).
Utilisé par l'éditeur de lien pour savoir comment mettre à jour la valeur du symbole. Le champ n_type est divisé en trois sous-champs par un masque de bits. L'éditeur de liens traite les symboles dont le bit N_EXT est positionné comme un symbole "externe" et permet de les référencer depuis un autre fichier binaire. Le masque N_TYPE définit les bits intéressant l'éditeur de liens :
N_UNDF
Un symbole indéfini. L'éditeur de liens doit localiser un symbole externe du même nom dans un autre fichier binaire afin d'en déterminer sa valeur absolue. Dans un cas spécial, si le champ n_value est non-zéro et qu'aucun fichier binaire ne définie ce symbole, l'éditeur de lien remplace le par une adresse du segment bss, réservant un nombre d'octet égal à n_value. Si ce symbole est indéfini dans plusieurs fichiers binaires et que ceux-ci ne sont pas d'accord sur la taille, l'éditeur de liens choisi la plus grande trouvée.
N_ABS
Un symbole absolu. L'éditeur de liens ne modifie pas un symbole absolu.
N_TEXT
Un symbole texte. La valeur de ce symbole est une adresse de texte et l'éditeur de liens la modifera lorsqu'il fusionnera les ficheirs binaires.
N_DATA
Un symbole de données. Similaire à N_TEXT mais pour les adresses de données. Les valeurs des symboles de texte et de données ne sont pas des positions mais des adresses. Pour retrouver une position dans un fichier, il faut trouver l'adresse de chargement du début de la section correspondante, la récupérer et l'ajouter à la position de la section.
N_BSS
Un symbole bss. Comme les symboles de texte et de données mais n'a pas de position correspondante dans le fichier binaire.
N_FN
Un symbole nom de fichier. L'éditeur de liens place ce symbole avant les autres lorsqu'il fusionne des fichiers binaires. Le nom du symbole est le nom de fichier donné à l'éditeur de liens et sa valeur est la première adresse de texte de ce fichier binaire. Les symboles nom de fichiers ne sont pas utiles à l'édition de liens ou au chargement mais le sont pour le débogage.
Le masque N_STAB définit les bits intéressant les débogeurs symboliques tels que gdb(1). Les valeurs sont décrites dans stab(5).
n_other
Ce champ fournit des informations sur la nature du symbole indépendament de sa localisation dans le segment, comme déterminé par le champ n_type. Actuellement, les quatre bits de poids faible du champ n_other prennent une des deux valeurs AUX_FUNC ou AUX_OBJECT (voir <link.h> pour leur définitions). AUX_FUNC associe le symbole à une fonction appelable et AUX_OBJECT à des données, indépendament de leur localisation dans le segment texte ou données. Ce champ est destiné à être utilisé par ld(1) pour la construction d'exécutables dynamiques.
n_desc
Réservé aux débogueurs. L'éditeur de liens n'y touche pas. Les divers débogueurs l'utilisent dans différents buts.
n_value
Contient la valeur du symbole. Pour ceux de type texte, données et bss, il s'agit d'une adresse. Pour les autres (comme ceux de débogage), la valeur est arbitraire.
La table des chaines est une longueur de unsigned long suivie de chaines terminées par le symbole null. La longueur représente la taille en octets de la table complète donc sa valeur minimale (ou la position de la première chaine) est toujours 4 sur les machines 32 bits.
VOIR AUSSI
as(1), gdb(1), ld(1), brk(2), execve(2), nlist(3), core(5), link(5), stab(5)
HISTORIQUE
Le fichier inclus a.out.h apparait avec la version 7 AT&T UNIX.
BUGS
Puisque tous les systèmes ne supportent pas le champ a_midmag, il peut être très difficile de déterminer à quelle architecture est destiné le binaire sans examiner le véritable code machine. Même avec un identifiant, l'ordre d'octets (byte order) de l'entête exec dépend de la machine. Personne ne semble d'accord sur ce que représente bss. De nouveaux formats de fichiers binaires seront supportés à l'avenir et ne seront probablement pas compatibles, à tout niveau, avec l'ancien format.
Puisque tous les systèmes ne supportent pas le champ a_midmag, il peut être très difficile de déterminer à quelle architecture est destiné le binaire sans examiner le véritable code machine. Même avec un identifiant, l'ordre d'octets (byte order) de l'entête exec dépend de la machine.
Personne ne semble d'accord sur ce que représente bss.
De nouveaux formats de fichiers binaires seront supportés à l'avenir et ne seront probablement pas compatibles, à tout niveau, avec l'ancien format.
BSD 5 juin 1993
Version française de Guillain Seuillot le 04 avril 2000