fonction en code binaire - Page 1

Bon voila j'ai de nouveau la même question que j'avais déja posé mais je n'avais jamais obtenu une réponse claire:
J'aimerais pouvoir ecrire UNE fonction en C que et OBTENIR le code binaire associé a cette fonction.
c'est a dire que si j'ecris la fonction:

ma_func:
movem.l d3-d7/a2-a6,-(a7)
ROM_CALL ngetchx
movem.l (a7)+,d3-d7/a2-a6
rts

je veux obtenir le bloc binaire associé a cette unique fonction.
Bien evidemment le code ne sera pas en assembleur mais en C.
Je suis persuadé que c'est juste une utilisation des executables tigcc mais je n'ai pas reussi a le faire.

heuu, tu mets un label à la fin de la fonction et tu copies la mem entre le pointeur sur la fonction et le label ?

ps : c plus detaillé dans la faq de tigcc pour avoir la taille d'une fonction je crois.

Pas bête mais ca m'oblige a recuperer le bloc associé on calc or je veux le bloc pour faire un truc on PC

ah, ok.
il doit falloir faire un fichier objet ou qq chose comme ça, je ne sais pas trop en fait..

Une solution bateau en attendant l'option -bin de ld-tigcc (Ou peut etre l'y est deja ?)

Tu rajouter au debut:
unsigned long = 0xDEADDEAD;
//Ton code./
unsigned long = 0xADAEADEA;

Et tu utlisies ttextract de la tict.

pas bete

mais ac le relogement y'aura pas des pbs ?

pas en ASM (a mon avis)

Pen^2
: mais ac le relogement y'aura pas des pbs ?

Si.

mastergb, il faudra vraiment que tu m'expliques ce que tu comptes faire exactement...

Je veux bien Kevin mais en PV....
Bon je peut le faire avec le debuggeur de virtual-ti mais c'est lourd...

faudrait modifier les offsets à la main et ajouter des entrées dans la table des symboles #arg#

bon courrage (c surement possible mais bon..)

et moi g pas le droit de savoir ?
sniff

Question de plus:
Dans le cas ou j'arriverais a recuperer ce bloc, si la fonction n'utilise aucune variable globale et que tout passe par les registres ou la pile est on obligé de faire une table de relocation.
Car comme dans l'exemple ci dessus il n'a ya aucune adresse relative...
(ca c'est une question pour kevin )

Dans ce cas, non, pas besoin de relogement (relocation), ça devrait marcher sans.

J'ai essayer avec les marquers de PpHd avec son code les valeurs hexa n'apparaissent même pas dans l'exe.
Par contre suivi d'un static si mais le compilo les range l'une a cote de l'autre...
Donc ca marche pas..

et si tu fais de l'asm inline ? il doit pas les bouger si ?

genre __asm { dc.l $deadcafe } etc ? (dsl pour la syntaxe )

Sinon, t'écris dans le .s généré et tu le réassembles

ouah ca je sais pas faire....

ça quoi ?

__MARK(begin_marker)
... fonction(...)
{
...
}
__MARK(end_marker)

Tu compiles ça en un programme complet et tu utilises ttextract sur le résultat.

tigcc -Os prog.c
ttextract prog.89z prog.bin begin_marker end_marker

Il y a l'infrastructure qu'il faut surtout parce que les premières releases de TIGCCLIB fonctionnaient comme ça.

KK> __MARK, j'ai jamais entendu parlé et j'ai pas trouvé dans la doc. C'est une nouveauté du .95?
L'utilisation d'un __MARK impliquerait-il le respect de l'ordre des fonctions et vars de la source?

par ex, si tu fais

__MARK(begin_marker)
... fonction1(...)
{
..
printf("hello word");
....
}


__MARK(middle_marker)
... fonction2(...)
{
...
}
__MARK(end_marker)

puis ttextract prog.89z func1.bin begin_marker middle_marker
et ttextract prog.89z func2.bin middle_marker end_marker

* Je suppose que la fonction1 sera bien dans func1.bin et la fonction2 dans func2.bin

*Mais la string "hello word", est il prévu qu'elle soit bien dans func1.bin?

Non, le string "hello world" ne sera pas dans func1.bin

C bien
: KK> __MARK, j'ai jamais entendu parlé et j'ai pas trouvé dans la doc. C'est une nouveauté du .95?

Non, c'est une ancienneté qui traîne dans tigcclib.h depuis longtemps déjà (et qui y restera parce que, comme tu vois, c'est utile).

L'utilisation d'un __MARK impliquerait-il le respect de l'ordre des fonctions et vars de la source?

Non, c'est un hack affreux (c'est un asm (".ascii ...");) qui marche parce que GCC émet les fonctions dans l'ordre.

par ex, si tu fais

__MARK(begin_marker)
... fonction1(...)
{
..
printf("hello word");
....
}


__MARK(middle_marker)
... fonction2(...)
{
...
}
__MARK(end_marker)

puis ttextract prog.89z func1.bin begin_marker middle_marker
et ttextract prog.89z func2.bin middle_marker end_marker

* Je suppose que la fonction1 sera bien dans func1.bin et la fonction2 dans func2.bin
*Mais la string "hello word", est il prévu qu'elle soit bien dans func1.bin?

Non. Ceci ne marche pas du tout si on utilise des chaînes de caractères.
La seule manière de laquelle tu peux utiliser une chaîne de caractères de manière fiable avec ça est:
char hello[]="hello world";
(tableau local automatique, pas un pointeur ou quelque chose de global ou statique).

Et dire que j'allais ajouter que je me demandais si ça gerait aussi la realloction table...

Je suppose qu'il n'est pas envisagé d'implémenter proprement un truc genre "mark" tel que tout ce qui soit entre deux marks soit compilé entre ces marks, y compris la string.
Puisque la réponse est (sans doute) non (et c'est pas une réponse si injuste), peut-être n'aurais tu pas du écrire tigcc -Os prog.c car je crois que quand je t'ai révélé utiliser ce hack tu m'as dit de pas le faire en C ou au moins d'utiliser -O0.

C bien
: Et dire que j'allais ajouter que je me demandais si ça gerait aussi la realloction table...

Évidemment que non. ttextract prend ce qu'il y a entre les 2 marqueurs dans le fichier binaire. La table de relogement n'en fait jamais partie.

Je suppose qu'il n'est pas envisagé d'implémenter proprement un truc genre "mark" tel que tout ce qui soit entre deux marks soit compilé entre ces marks, y compris la string. Puisque la réponse est (sans doute) non (et c'est pas une réponse si injuste),

La solution propre est de compiler un programme complet avec la fonction en question renommée en _main (mais là encore ce n'est pas propre du tout si la fonction prend des arguments ou retourne un résultat ), comme ça tu as ta chaîne et ta table de relogement.

peut-être n'aurais tu pas du écrire tigcc -Os prog.c car je crois que quand je t'ai révélé utiliser ce hack tu m'as dit de pas le faire en C ou au moins d'utiliser -O0.

Mais bonjour l'horreur générée comme code en -O0.
Je sais très bien que cette méthode risque de ne plus marcher avec les versions futures de GCC (et que compiler avec optimisation augmente le risque).

Le fait est tout simplement que les fonctions dans un fichier externe et chargeables une par une ne sont pas du tout prévues par le langage C. Ce n'est pas du Lisp.

Kevin, essaye de comprendre un peu l'ironie. Cette allusion à la réalocation table était référence au fait que j'imaginait que MARK était un truc légal bien foutu (dont j'aurrai pu me demander s'il gerrait la réallocation table) et que tout à coup en découvrant ton post les illusions cessent quand tu me dit que c'est juste .asciz. Inutile de me dire que ça gérait pas la réallocation table, si je ne l'avais pas su j'aurais utilisé une tournure comme Et ça gère même la réalocation table? C'est super alors. En général "et dire que j'allais..." indique que la situation a changé (d'ou l'imparfait) et est rarement marqueur du sérieux de ce qui suit. Je comprends mieux maintenant qu'on te matraque sur le topique [modérateurs] à propros de ta mauvaise compréhension de l'ironie.

Et pour l'optimisation, si c'est

ma_func:
movem.l d3-d7/a2-a6,-(a7)
ROM_CALL ngetchx
movem.l (a7)+,d3-d7/a2-a6
rts

elle fera pas grand chose, même si c'est ecrit en C!

C bien :
c'est juste .asciz

Petit détail: c'est .ascii, pas .asciz.