Tu n'est pas trés claire quand tu dis : "> Je souhaiterai utiliser les fonctions définits dans un fichier .o depuis un
fichier .c auxquel je le compile avec gcc en sortie .s."
"auxquel" et "le" désignent quoi ?
Au demeurant, si tu veux te servir des fonctions défini dans un fichier objet (extension .o), tu peux le faire sans avoir son fichier source (extension .c). Exemple, si dans ton .o tu sais qu'il y a une fonction "charger_parametres", alors tu peux appeler cette fonction dans ton fichier à toi (le .c que tu écrit) comme si elle y était écrite. Au moment de la compilation, il faut compiler ton fichier ".c" en ".o" avec l'option "gcc -c", ensuite tu compile les deux fichiers objets (le 1er .o et celui que tu viens de créer) avec "gcc fichier1.o tonfichier.o", et ça devrait marcher.
Bon courage.
Salut,
Tu n'est pas trés claire quand tu dis :
"> Je souhaiterai utiliser les fonctions définits dans un fichier .o depuis
un
fichier .c
auxquel je le compile avec gcc en sortie .s."
"auxquel" et "le" désignent quoi ?
Au demeurant, si tu veux te servir des fonctions défini dans un fichier
objet (extension .o), tu peux le faire sans avoir son fichier source
(extension .c).
Exemple, si dans ton .o tu sais qu'il y a une fonction "charger_parametres",
alors tu peux appeler cette fonction dans ton fichier à toi (le .c que tu
écrit) comme si elle y était écrite. Au moment de la compilation, il faut
compiler ton fichier ".c" en ".o" avec l'option "gcc -c", ensuite tu compile
les deux fichiers objets (le 1er .o et celui que tu viens de créer) avec
"gcc fichier1.o tonfichier.o", et ça devrait marcher.
Tu n'est pas trés claire quand tu dis : "> Je souhaiterai utiliser les fonctions définits dans un fichier .o depuis un
fichier .c auxquel je le compile avec gcc en sortie .s."
"auxquel" et "le" désignent quoi ?
Au demeurant, si tu veux te servir des fonctions défini dans un fichier objet (extension .o), tu peux le faire sans avoir son fichier source (extension .c). Exemple, si dans ton .o tu sais qu'il y a une fonction "charger_parametres", alors tu peux appeler cette fonction dans ton fichier à toi (le .c que tu écrit) comme si elle y était écrite. Au moment de la compilation, il faut compiler ton fichier ".c" en ".o" avec l'option "gcc -c", ensuite tu compile les deux fichiers objets (le 1er .o et celui que tu viens de créer) avec "gcc fichier1.o tonfichier.o", et ça devrait marcher.
Bon courage.
Sivaller
On peux certainement les compiler ;oui certe . Mais il me semble que cela ne marche pas en fichier de sortie .s (avec paramétre -S spécifié).
On peux certainement les compiler ;oui certe .
Mais il me semble que cela ne marche pas en fichier de sortie .s (avec
paramétre -S spécifié).
On peux certainement les compiler ;oui certe . Mais il me semble que cela ne marche pas en fichier de sortie .s (avec paramétre -S spécifié).
Pierre Maurette
"Sivaller" a écrit:
On peux certainement les compiler ;oui certe . Mais il me semble que cela ne marche pas en fichier de sortie .s (avec paramétre -S spécifié). J'ai du mal à suivre vos explications, et ne connais pas bien la
chaîne gcc. Mais si .s est une sortie assembleur, c'est normal que vous n'y arriviez pas, puisque elle est dans la chaîne de production du code antérieure à .o. -- Pierre
"Sivaller" <sivaller@sivaller.no-ip.org> a écrit:
On peux certainement les compiler ;oui certe .
Mais il me semble que cela ne marche pas en fichier de sortie .s (avec
paramétre -S spécifié).
J'ai du mal à suivre vos explications, et ne connais pas bien la
chaîne gcc. Mais si .s est une sortie assembleur, c'est normal que
vous n'y arriviez pas, puisque elle est dans la chaîne de production
du code antérieure à .o.
--
Pierre
On peux certainement les compiler ;oui certe . Mais il me semble que cela ne marche pas en fichier de sortie .s (avec paramétre -S spécifié). J'ai du mal à suivre vos explications, et ne connais pas bien la
chaîne gcc. Mais si .s est une sortie assembleur, c'est normal que vous n'y arriviez pas, puisque elle est dans la chaîne de production du code antérieure à .o. -- Pierre
Anthony Fleury
Sivaller wrote:
oui mais sans avoir le.c ;
Mais quel est le problème exacte ? Car là c'est pas clair du tout. Ce que j'en ai compris, soit deux fichiers :
- un .cpp avec un appel à une fonction toto() - un .o, fichier objet, qui est la compilation d'un .c[pp] qui définit toto().
Résultat attendu :
un fichier .s résultant de la compilation du .cpp ET contenant la définition en assembleur de toto(), en gros, un .s qui peut fonctionner tout seul et pourrait être compilé pour donner un executable sans lier avec le fichier .o.
Seulement comme le précisait Pierre, ce n'est pas possible. L'appel de toto() dans le .cpp ne pouvant pas être résolu dans celui ci, il le sera par l'éditeur de lien, phase « ultime » de la compilation, et donc qui se trouve APRÈS la construction du .s. Le .s est la sortie juste avant de faire le .o en gros, et contient le code assembleur correspondant au code C++ du .cpp. (donc avec les appels de fonctions). Après pour les fonctions dont le code n'est pas présent dans les .cpp, c'est à l'éditeur de lien de jouer son rôle. Mais le .s ne donnera jamais le code assembleur de tout l'executable de manière linéaire, c'est à dire en mettant le code assembleur de la fonction toto() dans le .s. Il serait bon de connaître le problème exacte pour répondre (d'ailleurs ici c'est super HS).
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Sivaller wrote:
oui mais sans avoir le.c ;
Mais quel est le problème exacte ?
Car là c'est pas clair du tout.
Ce que j'en ai compris, soit deux fichiers :
- un .cpp avec un appel à une fonction toto()
- un .o, fichier objet, qui est la compilation d'un .c[pp] qui définit
toto().
Résultat attendu :
un fichier .s résultant de la compilation du .cpp ET contenant la définition
en assembleur de toto(), en gros, un .s qui peut fonctionner tout seul et
pourrait être compilé pour donner un executable sans lier avec le
fichier .o.
Seulement comme le précisait Pierre, ce n'est pas possible. L'appel de
toto() dans le .cpp ne pouvant pas être résolu dans celui ci, il le sera
par l'éditeur de lien, phase « ultime » de la compilation, et donc qui se
trouve APRÈS la construction du .s. Le .s est la sortie juste avant de
faire le .o en gros, et contient le code assembleur correspondant au code
C++ du .cpp. (donc avec les appels de fonctions). Après pour les fonctions
dont le code n'est pas présent dans les .cpp, c'est à l'éditeur de lien de
jouer son rôle. Mais le .s ne donnera jamais le code assembleur de tout
l'executable de manière linéaire, c'est à dire en mettant le code
assembleur de la fonction toto() dans le .s.
Il serait bon de connaître le problème exacte pour répondre (d'ailleurs ici
c'est super HS).
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
Mais quel est le problème exacte ? Car là c'est pas clair du tout. Ce que j'en ai compris, soit deux fichiers :
- un .cpp avec un appel à une fonction toto() - un .o, fichier objet, qui est la compilation d'un .c[pp] qui définit toto().
Résultat attendu :
un fichier .s résultant de la compilation du .cpp ET contenant la définition en assembleur de toto(), en gros, un .s qui peut fonctionner tout seul et pourrait être compilé pour donner un executable sans lier avec le fichier .o.
Seulement comme le précisait Pierre, ce n'est pas possible. L'appel de toto() dans le .cpp ne pouvant pas être résolu dans celui ci, il le sera par l'éditeur de lien, phase « ultime » de la compilation, et donc qui se trouve APRÈS la construction du .s. Le .s est la sortie juste avant de faire le .o en gros, et contient le code assembleur correspondant au code C++ du .cpp. (donc avec les appels de fonctions). Après pour les fonctions dont le code n'est pas présent dans les .cpp, c'est à l'éditeur de lien de jouer son rôle. Mais le .s ne donnera jamais le code assembleur de tout l'executable de manière linéaire, c'est à dire en mettant le code assembleur de la fonction toto() dans le .s. Il serait bon de connaître le problème exacte pour répondre (d'ailleurs ici c'est super HS).
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Sivaller
Oui je comprend ; le fichier .o est générer aprés le .s ; peux t'on donc avec as86 compiler un .s faisant appel à des fonctions externes définit dans d'autres fichiers .o ?
Oui je comprend ;
le fichier .o est générer aprés le .s ;
peux t'on donc avec as86 compiler un .s faisant appel à des fonctions
externes définit dans d'autres fichiers .o ?
Oui je comprend ; le fichier .o est générer aprés le .s ; peux t'on donc avec as86 compiler un .s faisant appel à des fonctions externes définit dans d'autres fichiers .o ?
