Passage d’arguments GCC != SAS/C
8 sujets de 1 à 8 (sur un total de 8)
-
Afin de faciliter le portage, je suis en train de passer la version 68k de Feelin sous GCC. Tout allait pour le mieux jusqu’à ce que, horreur et crème de banane, la démo « thread » me pose des problèmes:
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> thread_main: Obj (0x1046DD8C), userdata (0x104632DC)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> entry(0x1046DD8C, 0x104632DC, 0x1046DD8C)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> Thread_Main(0x10427C60, 0x1046E0C8, 0x1046DD8C)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> (db)F_DoA() 0x10427C60 is not an Object !! Class 0x61727900 - Method 0xD0000041 (Pop)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> waiting...
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> (db)F_DoA() 0x10427C60 is not an Object !! Class 0x61727900 - Method 0xD0000042 (Wait)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> (db)F_DoA() 0x10427C60 is not an Object !! Class 0x61727900 - Method 0xD0000041 (Pop)
07-Jan-30 18:07:28 [test.thread] Thread{1046DD8C}.Send> waiting...
Après une demi-heure à me pourquoi les arguments reçus pas Thread_Main() ne corresponde pas à ceux passés, je tente une recompilation de la démo par GCC, c’est la stupéfaction:
07-Jan-30 07-Jan-30 NEW SESSION ***
07-Jan-30 18:16:56 [test.thread] Thread{105D45B4}.Send> thread_main: Obj (0x105D45B4), userdata (0x10650C3C)
07-Jan-30 18:16:56 [test.thread] Thread{105D45B4}.Send> entry(0x105D45B4, 0x10650C3C, 0x105D45B4)
07-Jan-30 18:16:56 [test.thread] Thread{105D45B4}.Send> Thread_Main(0x105D45B4, 0x10650C3C, 0x105D45B4)
07-Jan-30 18:16:56 [test.thread] Thread{105D45B4}.Send> Msg 0x10650A82 - Action 0xFFFFFFFE
07-Jan-30 18:16:56 [test.thread] waiting...
07-Jan-30 18:16:56 [test.thread] waiting...
07-Jan-30 18:17:01 [test.thread] Msg 0x10650AEE - Action 0xFFFFFFFF
07-Jan-30 18:17:01 [test.thread] bye
07-Jan-30 18:17:01 [test.thread] THREAD_MAIN: EXIT - process (0x106AB6A8) thread port (0x105D7E28) >> BEGIN
07-Jan-30 18:17:01 [test.thread] THREAD_MAIN: EXIT - FLUSH MSG PORT
07-Jan-30 18:17:01 [test.thread] THREAD_MAIN: EXIT - RELEASE ARBITER
07-Jan-30 18:17:01 [test.thread] DEATH MSG (0x10650AEE)
07-Jan-30 18:17:01 [test.thread] .0xD0000042> THREAD_MAIN: EXIT - PURGE THREAD PORT: port (0x105D7E28)
07-Jan-30 18:17:01 [test.thread] .0xD0000042> THREAD_MAIN: EXIT >> DONE
Ben voilà, là ça marche parfaitement ! Est-ce que quelqu’un pourrait m’expliquer pourquoi le passage d’arguments ne se fait pas de la même façon entre GCC et SAS/C ? Ce qui est très ennuyeux !! :'(
Une solution serait également la bienvenue.
Merci Ô dieux de la programmation !
Crotte bleu ! Bêtement j’imaginais que si le code était « extérieur » il passait les arguments par la pile… il va donc falloir que je force le passage par les registres… Pff c’est moche pour la portabilité
En même temps je peux utiliser des registres pour m68k et laisser tel quel pour les autres, vu qu’ils compilent tous avec GCC. Heureusement la définition de la fonction d’entrée du Thread est une macro 
Merci Henes !! T’es le plus beau (de loin) !
mé… tous les appels systèmes se font de cette manière sous OS4…
Non. Depuis le ppc, les appels se font via une version modifiée de l’abi sysv. Le premier entier est dans r4 au lieu de r3, le 2e dans r5 au lieu de r4, etc… et je ne sais plus quel argument caché est passé dans r3 (la libbase ?).
avec GCC, le mot clé magique est VARARGS68K pour passer les arguments dans la pile.
C’est un define qui cache la véritable extension apportée au gcc hyperos. Extension qui n’existe pas dans le gcc 68k de gofromiel.
Et de toute façon, un tel exe passe une vararg par la pile ppc. Ce qui n’aide pas trop à récupérer tout argument passé sur la pile 68k
Pour cela il faut aller jouer avec le a7 émulé.
et je ne sais plus quel argument caché est passé dans r3 (la libbase ?).
Je ne sais pas si c’est dans r3 ou ailleurs, mais l’argument « caché » c’est l’interface à laquelle appartient la fonction appellée. D’ailleurs je ne sais pas si c’est également le cas pour les fonctions « internes » à son code (i.e. quand on fait pas appel à des fonctions appartenant à une interface), je n’ai pas désassemblé mes progs (et puis ça m’avancerait pas beaucoup je n’y connais rien en ASM PPC
Et de toute façon, un tel exe passe une vararg par la pile ppc. Ce qui n’aide pas trop à récupérer tout argument passé sur la pile 68k
Je ne comprends pas trop ce que tu veux dire
mais toujours est-il qu’il est possible de récupérer le tout (plutôt que un à un) en utilisant va_startlinear()/va_getlinearva() plutôt que va_start()/va_arg(). D’ailleurs je ne sais pas si c’est également le cas pour les fonctions « internes » à son code (i.e. quand on fait pas appel à des fonctions appartenant à une interface)
Je crois que cela concerne uniquement les fonctions dont le prototype est décoré avec l’hyperionesque extention « LIBCALL » ou quelque chose de similiaire.
Les autres utilisent sans doute l’abi naturelle du compilateur. Donc sysv.
Je ne comprends pas trop ce que tu veux dire mais toujours est-il qu’il est possible de récupérer le tout (plutôt que un à un) en utilisant va_startlinear()/va_getlinearva() plutôt que va_start()/va_arg().
Normalement, ce genre d’extension a uniquement été introduit pour facilement adapter les sources passant les arguments de leur taglist via une vararg.
Les contraintes d’alignement de la pile étant différentes pour 68k et ppc, je ne sais pas s’il est possible de l’utiliser dans hyperos pour faire ce que gofromiel avait à l’esprit.
Et il faudrait que la même pile soit utilisée par les codes 68k et ppc, comme c’est le cas dans warpup. Ce qui expliquerait que tous les programmes 68k plantent hyperos lorsqu’on ne les lance pas avec une pile plus importante que celle pour laquelle ils ont été conçus, au passage
En tout cas, le plus simple et compatible reste d’implémenter cela comme les hooks : les arguments dans des registres 68k et voilà.
8 sujets de 1 à 8 (sur un total de 8)
- Vous devez être connecté pour répondre à ce sujet.
