Bug de l'émulation de jsr par TiEmu (meme pas vrai d'abord :o) - Page 1

68kPM.pdf dit ça, page 83 : JSR <ea> : SP – 4 → SP; PC → (SP); Destination → PC
Ca laisse donc entendre que SP est ajusté avant que (SP) soit copié dans PC. Donc PC devient SP d'après jsr, pas d'avant.

J'ai écrit ce programme de test :

folco@Foch:~$ cat test.asm
        include "os.h"

        xdef    _nostub
        xdef    _ti92plus

__main: move.w  #$4E75,-(sp)    ; rts
        move.w  #$4E71,-(sp)    ; nop
        jsr     (sp)
        addq.l  #4,sp
        rts

Le but est d'essayer de faire exécuter la séquence nop // rts sur la pile.
Sur TiEmu, ça marche :
On voit en effet que PC vaut SP+4. Donc PC est modifié avant que SP ne soit décrémenté par jsr, ce qui va à l'encontre du document de Motorola.

Cependant, sur real calc, ça crash, ce qui voudrait dire que le document de Motorola est bien écrit.




ps -> A quoi sert cette technique ? A faire du SMC, mais en exécutant le code modifiant dans la pile, dans un contexte d'exécution en read-only. Ici, toutes mes directives IF* sont identiques, à l'exception du test à réaliser. C'est ce test que je pousse dans la pile :
https://sourceforge.net/p/asoc/code/HEAD/tree/src/directiv.asm#l101 pour le code des directives
https://sourceforge.net/p/asoc/code/HEAD/tree/src/directiv.asm#l178 pour le code commun.
Le workaround, pour utiliser cette technique, est de faire un pea after(pc) // jmp 4(sp) // after:. J'ai pas testé, mais à l'évidence ça devrait marcher.




Hey Kevin, un autre trick pour fooler les désassembleurs de HW4Patch ! \o/

Je crois que c'est pour toi

Tu es sur que ca ne crash pas parceque la pile n'est pas executable?

Je vois rien de ce genre dans j89hw.txt

Par contre, j'ai l'impression d'avoir tout faux en effet : les deux versions (jsr/pea-jmp) fonctionnent sous PedroM, mais pas sous AMS. Donc en fait, tout va bien.

Mais alors, comment ça se fait que ça plante sous AMS ? J'ai vu nulle part que la pile était exec-protected ><

ps -> Zerosquare a testé pour vous : ça marche aussi en x86

Merci Godzil Voilà ce que c'est de tester sous PedroM, sur ému, et sous AMS, on-calc


Parce que je sais que le trick le fera marrer, et lui resservira à l'occasion

Donc au final :
- la doc de Motorola est fausse
- la barre noire sous AMS n'indique pas le type d'erreur
- je ne vois pas de spécification concernant l'exécutabilité © de la pile sous AMS

Je viens de tester sous Steem (émulateur Atari relativement précis). Il émule jsr (sp) comme dans la doc de Motorola. Faut donc utiliser jsr 2(sp) pour que l'astuce de Folco marche.

Faut que je teste sur la Jaguar pour voir ce que ça fait

Je serais très intéressé par des tests sur d'autre matériel qu'une TI, oui.

ps -> pourquoi jsr 0(sp) ne fonctionnerait pas sur ton ému ? fais gaffe, certains assembleurs crétins se permettent de virer le 0 sans prévenir.

Au pire, tu devrais pouvoir hardcoder ça : dc.w $4EAF,0

Arg ! Tu cherches les ennuis là !

Je fais honneur aux capacités de PedroM

A part ça, tu sais quelque chose à propos d'une protection anti-exécution dans la pile d'AMS ?

Et après on dit que j'utilise des techniques de gorret, l'autre il executé du code dans la pile !!!!

Déjà pour quoi faire cela ? Petit coquin !!

Cela pourrait pas venir du prefetch du 68000 ? J'ai dejà vu des protections sur Atari qui faisait ce genre de chose, Du fait du prefetch suivant que tu lancais le code sous debugger ou sur vrai machine, cela avait pas du tout le même résultat.
Prefetch qui n'ai jamais respecter dans les émulos, d'ailleurs certains jeux de 2 instructions font moins de cycles quand elles sont ensembles.

GT Pas reveiller et Folco il m'embete !!

C'est parce que mon code s'exécute dans un endroit read-only, et que je veux faire du smc : pas d'autre moyen que de l'exécuter sur la pile (ou dans le heap, mais on va dire que je peux pas non plus). Cf le PS de ./1.
Le smc est là pour convertir le résultat d'un test façon BCC (lt/le/gt/ge etc...) en résultat de test BEQ/BNE. Ca rend tous ces tests génériques, grace à la magie de SCC, et ça permet de mutualiser la quasi-intégralité du code de ces directives.

J'ai bien pensé au prefetch, mais si c'était à cause de ça, ça ne fonctionnerait pas sous PedroM, hors là ça marche.

Ca ne me choquerais pas plus que ca que la pile utilise par AMS soit protege en execution (par defaut)

Du code dans un read only ? O_o

Peux tu me situer un peux plus le contexte ?

SMC obligatoire ? Tu peux pas 'taper/modifier/bricoler' le CCR ? En place ? Je suppose que tu as envisagé toutes les solutions.

GT Dans le gaz !!

Ca marche sur une vraie machine, alors pourquoi regarder plus loin ?

C'est pour cela que j'utilise pas d'émulateur: c'est souvent très lent, ou il faut une machine qui tourne 100 fois plus vite O_o Ca émule pas toutes les 'features (Bug/bricolages, etc...)

Même un debugger sur la machine même peux (Justement dans le cas du prefetch) te donner de mauvaises valeurs.


GT Sur la vraie machine

C'est bien pour ça que j'ai vérifié sur vraie machine, pour ce genre de tricks, je fais pas confiance aux émus ^^
Le reste du temps, un ému sur PC est quand meme bien commode, surtout que devoir éditer sur TI, c'est pas franchement le pied (c'est pour ça que je fais un assembleur on-calc, logique )

GT Turbo (./16) :
Du code dans un read only ? O_o
Peux tu me situer un peux plus le contexte ?

La mémoire Flash est exécutable sous Pedrom, mais tu peux pas la modifier comme ça.
L'avantage, c'est que ça permet d'exécuter les programmes en Flash et pas en RAM, ça permet de faire tourner de plus gros programmes.

Donc :
-> exit les variables en section de code
-> exit les BSS
-> exit les relogements
-> donc exit les appels de DLL, les appels système (libc) et les autres appels système (ramcalls)

Sauf en s'y prenant comme ça : blogs/blog.php?id=400&i=46
On retrouve les appels de libc et de DLL pour un overhead d'un jmp x.l en temps d'exécution, et pour 6 octets dans la pile, là où sont logés les trampolines.
Les ramcalls sont supportés via le handler de F-Line depuis la version précédente de PedroM.

GT Turbo (./16) :
SMC obligatoire ? Tu peux pas 'taper/modifier/bricoler' le CCR ? En place ? Je suppose que tu as envisagé toutes les solutions.

Les liens du code sont dans le ./1 si tu veux voir en détail. Là, le code de 6 directives est mutualisé dans une seule fonction, avec un overhead de 6 octets (réductible à 4, mais #flemme#) par fonction. Je pense difficilement pouvoir faire mieux.
Tout ce que tu proposes est évidemment possible, mais ça oblige chaque fonction à le faire, en plus d'octets, + les appels à (aux !) partie(s) du code mutualisable, ça prendrait forcément bien plus de place, et amha ça perdrait en lisiblité.

Tu met du code dans la section Data


GT

Les sections habituellement appelées .data et .code ne forment qu'une seule section sur TI. En fait, le code est considéré comme de la data (il est donc modifiable), sauf pour moi qui exécute en Flash.

Folco (./12) :
A part ça, tu sais quelque chose à propos d'une protection anti-exécution dans la pile d'AMS ?

Ben si tu n'as pas installé hw3patch ou preos, la pile sous ams est protégée en éxécution sur hw>=2.

Ah, j'ai une HW2... D'habitude, j'ai PreOS, mais vu que j'avais oublié le bra * lors du premier run, j'ai fait un reset, et j'ai pas réinstallé PreOS. Ca m'apprendra !
Merci bien pour l'info en tout cas.

Je suis étonné que ça fonctionne effectivement sur un vrai 68k.
J'ai fait des tests en me disant que ça ne crache pas forcement car ça dépendrait de la valeur du PC mais même en m'arrangeant pour avoir la valeur de PC inscrit dans la stack équivalent à des instructions illegals, le PC vaut bien SP avant le pré-décrément.

Au final on a bien après exécution du jsr sur la prochaine instruction :
PC = SP
SP = SP-4

du coup il exécute bien le "nop rts" de ton exemple.

Probablement qu'en interne la valeur du registre passe par un chemin qui n'est pas soumis au pré-décrément.

je me méfierais de cette feature pour les autres modèle de 68k

SCPCD (./23) :
je me méfierais de cette feature pour les autres modèle de 68k

Je me suis fait la réflexion, oui

SCPCD (./23) :
Je suis étonné que ça fonctionne effectivement sur un vrai 68k.
J'ai fait des tests en me disant que ça ne crache pas forcement car ça dépendrait de la valeur du PC mais même en m'arrangeant pour avoir la valeur de PC inscrit dans la stack équivalent à des instructions illegals, le PC vaut bien SP avant le pré-décrément.

Au final on a bien après exécution du jsr sur la prochaine instruction :
PC = SP
SP = SP-4

du coup il exécute bien le "nop rts" de ton exemple.

Probablement qu'en interne la valeur du registre passe par un chemin qui n'est pas soumis au pré-décrément.

je me méfierais de cette feature pour les autres modèle de 68k

Et sur ton Super68K a 1Cycle ca marche ?

j'ai pas testé, mais je pense que ça ne devrait pas fonctionner.
De mémoire il doit exécuter le pré-décrément avant d'utiliser le contenu.
Donc faudra probablement que je fasse une correction.

Bon, une imprécision de la doc de GCC4TI :
INCLUDE "filename.h" : Includes the file given as a parameter at the current source position. The file is read in as assembly source code, as if it was part of the current assembly source.
En fait, A68k supporte aussi include 'file.h' et include file.h. Féchier.

Sujet super interressant mais une petite question :

T'a pile se situe ou ?

Car vu que tu écris / lit dedans cette partie est accessible sans soucis non ?

Si oui place ton code dedans et réduit ta pile

GT Sans pile !!

GT Turbo (./28) :
T'a pile se situe ou ?

Qqpart en RAM, dans un endroit alloué par l'OS

GT Turbo (./28) :
Car vu que tu écris / lit dedans cette partie est accessible sans soucis non ?

en rw, oui

GT Turbo (./28) :
Si oui place ton code dedans et réduit ta pile

je comprends mal l'idée. Je peux pas déplacer ou réduire la pile comme ça, le système aura toujours sa pile de 16 ko de toute façon. Evidemment, je peux allouer de la mémoire, et faire pointer SP en haut pour utiliser "ma pile", de la taille que je veux, mais j'en vois pas vraiment l'intéret, sauf si j'ai besoin de plus de 16ko, ce qui n'est pas le cas.

Bon mon Falcon étant chaud, j'ai essayé, sur un 060 ca fonctionne très bien.

GT Sur un 060 !!