1

yop,

C'est la première fois que j'utilise cette fonction, je crois. D'après la doc :
	It relocs the library, calls the function and unreallocs the library.
	The parameters pushed on the stack are corrupted.
	If there is an error, the parameter 'lib_name' equals zero after the call.

Et dans le code (sld.asm, ligne 1226) :\next subq.l #8,a7 ; Fix stack ptr. movem.l d0-d7/a0-a7,-(a7) ; Pop a7 to increase Stack Frame GET_DATA_PTR ; Get a6 subq.l #4,a7 ; Create Stack Frame \UnrelocLib: move.l (LibsExecList-Ref)(a6),a3 move.l (a3),a5 ; Read Lib Ptr bsr kernel::unrelocation ; Unreloc & delete. \FreeNode: move.l (LibsExecList-Ref)(a6),a3 ; Kernel::relocation may destroy all registers if an error occured ! (execpt a6 & a5) move.l -(a3),(4*16)(a7) ; Set Return Address move.l -(a3),(LibsExecList-Ref)(a6) ; Set new head move.l a3,(a7) ROM_THROW HeapFreePtr ; Free Node moveq #1,d7 ; Set no error \AllocError addq.l #4,a7 ; Fix stack move.l d7,(4*16)(a7) ; Set error \end: movem.l (a7)+,d0-d7/a0-a6 rts
Le \next est le point de "réentrance" de LibsExec après que la fonction de la lib désirée ait été exécuté. Comme on voit, le moveq #1,d7 est exécuté après le \FreeNode. C'est le code de retour de LibsExec, qui se retrouve à (sp) au retour au programme appelant. Mais si l'initialisation de la librairie échoue, LibsExec saute à \Freenode, ce qui fait que dans tous les cas, on se retrouve avec un code de retour de 1, même en cas d'erreur (dans mon cas, la lib n'est pas présente sur la calc).

Au passage, il y a une petite erreur dans l'exemple de la doc : Example: pea arg2function ; Arg2 of the function move.w #arg1function,-(a7) ; Arg1 of the function move.b #1,-(a7) ; Version 1 move.w #3,-(a7) ; Function 3 pea LibsName ; Libs Name move.w #145,d0 ; D0 = 145 for the function ! jsr kernel::LibsExec tst.l (a7) lea (2+4+2+2+2+4)(a7),a7 ; Does not affect the flag
Le premier 2 est manifestement en trop, t'as dû compter par mégarde l'argument de d0.

Voilà, si tu veux, je mets mon bureau d'étude sur un patch afin de corriger cette gravissime faille de sécurité cheeky


(edit -> post Zeph-syntax-colorized-powered)

2

Call : PpHd appelé(e) sur ce topic...

3

Bon PpHd, qu'est-ce que cette histoire de bug ? Après Folco est contrarié, il passe la nuit devant son PC et son épouse n'est pas contente embarrassed
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

4

Tiens, au boulot je me suis demandé pourquoi un LibsExec ne pourrait pas être un LibsBegin + LibsCall. LibsCall fait (presque) explicitement un LibsPtr + jsr (a0). Faut que j'investigationnise, parce que LibsExec appelle explicitement les fonctions de relocation. PpHd, si t'as la réponse, ça m'éviterait de chercher le pourquoi du comment ! grin

5

!Wrong section
WONT FIX

6

Lol grin
C'est parce que le forum t3 n'est plus en première page, et comme d'habitude je m'attendais à des réactions ou des solutions, et comme d'habitude il n'y en a pas eu cry

7

Voilà. Mais j'ai malheureusement pas pu poster dans ma catégorie vu qu'il ne s'agit pas de PedroM directement, mais de PreOS tsss grin
topics/155985-bug-de-libsexec#0