Discussion :

[jeroman]

Bonsoir,

mon titre n'est pas très clair. Je vais essayer de développer de manière plus claire.

J'ai deux fichiers très simples :

fichier1.c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
#include <stdio.h>
 
void fonction_bidon()
{
	printf("hello !");
}

main.c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
extern void fonction_bidon();
 
int main()
{
	fonction_bidon();
	return 0;
}

Je compile les deux fichiers séparément. J'obtiens donc deux fichiers : main.o et fichier1.o

J'en arrive à ma question. Mon fichier 'main.c' sait qu'il existe une 'fonction_bidon()' mais ne sait rien de plus à son sujet. Voici le code assembleur de 'main.o' que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
int main()
{
   0:	55                     	push   ebp
   1:	89 e5                	mov    ebp,esp
   3:	83 e4 f0             	and    esp,0xfffffff0
   6:	e8 00 00 00 00       	call   b <main+0xb>
			7: DISP32	__main
	fonction_bidon();
   b:	e8 00 00 00 00       	call   10 <main+0x10>
			c: DISP32	fonction_bidon()
	return 0;
  10:	b8 00 00 00 00       	mov    eax,0x0
}
  15:	c9                   	leave  
  16:	c3                   	ret    
  17:	90                   	nop

Les deux CALL ont pour adresse relative 0 (E8 00 00 00 00), ce qui semble-t-il est la valeur donnée par défaut lorsque le compilateur ne connait pas l'adresse définitive. Je suppose que chaque fichier objet généré contient un tableau contenant toutes les adresses (par exemple, ici, les adresses 0x0007 et 0x000C) où la valeur devra être remplacée par la valeur définitive lors de la génération de l'exécutable.
Comment et où sont stockées ces données dans ce fichier ? J'ai beau chercher dans les options de l'outil 'objdump', mais je ne trouve rien à ce sujet. L'ouverture du fichier dans un éditeur hexadécimal semble ne rien donner non plus : je vois bien le nom des symboles mais rien qui pourrait correspondre à des adresses où des valeurs devraient être remplacées. Dans le code assembleur généré, on aperçoit que 'objdump' sait déjà qu'aux adresses 0x0006 et 0x000B, il y a une instruction CALL qui lancera respectivement les fonctions '__main' et 'fonction_bidon()'.

Merci.

[dinobogan]

Je comprend mal ta question. Les adresses seront résolues au linkage.
S'il y a un appel de fonction mais pas de définition, l'édition des liens entre les objets sortira en erreur.

[jeroman]

En réalité, ma question est très simple (si, si ! ), mais je peine à l'expliquer par écrit.

J'ai bien compris que l'éditeur de liens résout les adresses, mais comment peut-il justement "deviner" à quelles positions (dans le code objet) ces adresses doivent être modifiées afin qu'elles correspondent aux fonctions désirées ? Car le code machine n'est qu'une succession d'instructions CPU et l'éditeur de liens n'est pas censé savoir ce qui doit être modifié dedans lors du linkage vu que ce n'est pas lui qui a compilé les codes sources.

Je suppose donc qu'il existe une table dans le fichier objet qui lui fournit ces renseignements ? Une table du style :
#1 : A la position 0x0007 -> remplacer les 4 octets afin que la valeur du CALL (instruction E8, déplacement relatif) corresponde à l'adresse de '__main'
#2 : A la position 0x000C -> remplacer les 4 octets afin que la valeur du CALL (instruction E8, déplacement relatif) corresponde à l'adresse de 'fonction_bidon()'

Je cherche simplement à savoir si ma supposition était bonne.

[Christophe]

C'est géré par la table de relocation.

Pour linux :
Pour aller plus loin : rechercher le fonctionnement des sections .got et .plt du format ELF
C'est très technique :
https://www.segmentationfault.fr/lin...plt-got-ld-so/

Pour Windows :
Sous Windows, le concept est le même, mais s'appuie sur le format de fichier exécutable PE.

[jeroman]

Merci beaucoup ! Je vais continuer mes recherches de ce côté.

[LittleWhite]

Bonjour,

Le question est intéressante. Je n'ai pas de réponse, mais récemment, j'ai croisé des éléments pouvant y répondre. D'abord ici, mais surtout la documentation ici.