info sur l'execution de programme dans un programme - Page 2

-

Je sais, j'ai vu aussi du code compilé par tigcc (pas besoin de désassambler).

essaye de faire une boucle for (enfin, l'équivalent) qui affiche un milliers de fois un texte à l'écan avec drawstr sans restaurer la pile dedans...
ça plantera

(vu que tu empile, tu empile, tu empile... et au bout d'un moment, tu dépasse de la pile)
(du moins, j'ai testé une fois sans m'en rendre compte, et ça a planté... là, je me suis dit que ct pas toujours une bonne idée)

En effet, ça n'est pas une bonne idée de ne pas dépiler... Dans certaines conditions, ça risque de faire planter... Utilise d'autres méthodes...

-

Orion_> Ben ta méthode est bonne dans la plupart des cas, par exemple dans MLaby68k, mais dans certains cas elle peut être mauvaise, c'est tout, il faut que tu l'utilises intelligement, et voir si la pile ne risque pas d'être pleine.

XDanger> Ca veut dire quoi 'Utilise d'autres méthodes'? Que c'est sale? Si il sait qu'il n'empilera pas plus de 20 octets, il peut garder cette méthode, c'est encore dans les limites du raisonnable. Cette méthode est pas mauvaise seulement il ne faut pas en abuser et l'utiliser intelligement. D'ailleurs comme il le dit TIGCC l'utilise dans certains cas.

Orion_
a écrit : alors p koi TIGCC l'utilise t'il ????

Pour GDB ? En tout cas utiliser -fomit-frame-pointer fait économiser un peu de place.

moi avant je faisait pareil, sauf que au lieu du link, je restaurais tout d'un grand coup à la fin avec un seul lea x(a7),a7

ATTENTION
La méthode que je t'ai donnée dans le message #10 marche si et seulement si le sous-programme est à l'intérieur du fichier programme. Elle ne marche pas avec un programme externe, à cause de la protection anti-exécution des HW2. Dans ton cas, il faut:
1. faire en sorte que ton lanceur décompresseur soit exécuté en l'espace fantôme. Si tu ne veux pas attendre TIGCC 0.95 bêta 1 avec lequel il sera très simple d'importer le code pour EXECUTE_IN_GHOST_SPACE en assembleur, tu peux utiliser le code suivant de tipatch.lib:

debut_programme:
        lea debut_programme,%a0
        move.l %a0,%d0
        cmpi.l #0x40000,%d0
        jbcc __ghost_done
        bset.l #18,%d0
        clr.l %d1
        move.w (%a0,-2),%d1
        add.l %d0,%d1
        subq.l #1,%d1
        move.l %d1,-(%sp)
        move.l %d0,-(%sp)
        movea.l 0xC8,%a0
        movea.l (%a0,1384),%a0
        jsr (%a0)
        addq.l #8,%sp
        movea.l 0xC8,%a0
        cmpi.l #1000,(%a0,-4)
        jbcc __ghost_install
        pea __ghost_done(%pc)
        bset.b #2,(%sp,1)
        rts
__ghost_install:
        movem.l %a2-%a6/%d3-%d7,-(%sp)
        lea (%sp,-20),%sp
        move.l #0x3E000,%a3
        move.l %a0,%d0
        andi.l #0x600000,%d0
        addi.l #0x20000,%d0
        move.l %d0,(%sp,12)
        move.l %d0,(%sp,16)
        trap #0xC
        move.w #0x2700,%sr
        move.l #0xF,%d3
        pea __ghost_cont(%pc)
        bset.b #2,(%sp,1)
        clr.w  -(%sp)
        move.l 0xAC,%a0
        jmp (%a0)
__ghost_cont:
        lea (%sp,20),%sp
        movem.l (%sp)+,%a2-%a6/%d3-%d7
__ghost_done:

(J'ai changé tigcc_compiled. en debut_programme, mais sinon, c'est exactement le code de tipatch.lib. C'est à mettre au tout début du programme lanceur. Ne touche pas à ce code, même pas pour changer une ligne, si tu ne sais pas exactement ce que tu fais!!!) et
2. ajouter 0x40000 à l'adresse du programme à lancer. Dans ton cas:
adda.l $40000,a1

Et ce que je ne comprends pas, c'est pourquoi il y a tellement de personnes qui veulent absolument écrire un lanceur sans savoir ce qu'elles font. Heureusement qu'il y a le code tout prêt pour EXECUTE_IN_GHOST_SPACE.

-

Orion_
a écrit : il est normal donc que je te demande : sa fait koi exactement "EXECUTE_IN_GHOST_SPACE" ??

http://tigcc.ticalc.org/doc/httigcc.html#advanced_ghostspace

pourquoi faut t'il l'utiliser ici ?

Parce que:
- tu ne peux pas lancer le programme dans l'espace d'adresses normal à cause de la protection anti-exécution des HW2.
- tu ne peux le lancer dans l'espace fantôme que si l'espace fantôme a déjà été déprotégé. Or, cette déprotection reprotège l'espace d'exécution normal de ton lanceur. D'où la nécessité de déprotéger l'espace fantôme et de continuer l'exécution de ton lanceur en l'espace fantôme, comme le fait EXECUTE_IN_GHOST_SPACE.

pourquoi sa marche trés bien avec un programme que j'ai tester dans la version actuelle qui n'utilise pas "EXECUTE_IN_GHOST_SPACE" ??

Parce que:
- soit tu as testé sur une HW1 ou sur VTI.
- soit tu as eu de la chance et ton lanceur a été lancé en fin de RAM, ce qui déprotège la fin de la RAM, ce qui déprotège l'espace fantôme. Ça arrive souvent parce que AMS utilise un HeapMoveHigh avant de lancer les programmes, mais ce n'est pas toujours le cas!

XDanger> Ca veut dire quoi 'Utilise d'autres méthodes'? Que c'est sale? Si il sait qu'il n'empilera pas plus de 20 octets, il peut garder cette méthode, c'est encore dans les limites du raisonnable. Cette méthode est pas mauvaise seulement il ne faut pas en abuser et l'utiliser intelligement. D'ailleurs comme il le dit TIGCC l'utilise dans certains cas.

OK. Mais imagine que le truc nécessite beaucoup de pile, et qu'il soit lancé alors qu'il y a du bazar sur la pile (pas très courant, mais avec certains shells qui restent éventuellement sur la pile, ou des trucs comme ça). Si tu ne dépiles pas, tu risques de déborder. Ce genre de méthodes (ne pas dépiler) est à proscrire lorsqu'il y a des boucles longues, c'est plus sûr...

Tant qu'on n'empile pas plusieurs KO sans rien dépiler, c'est bon. D'ailleurs, si votre programme utilise beaucoup la pile, vous avez intérêt à définir le flag correspondant défini là.

Un programme ne devrait jamais utiliser pls de 90% de la pile, a mon avis.
Ne pas prevoir etre lance d'un shell est une erreur (Et ne me parle pas de la heap, c'est la responsabilite du shell).

PpHd a écrit :
Un programme ne devrait jamais utiliser pls de 90% de la pile, a mon avis. Ne pas prevoir etre lance d'un shell est une erreur (Et ne me parle pas de la heap, c'est la responsabilite du shell).

Moi, je trouve que c'est de la responsabilité du shell de laisser la pile libre. Le TICT Explorer le fait très bien. Mais comme il y a des auteurs de shells trop paresseux pour le faire, les programmes ont maintenant la possibilité d'avertir ces shells qu'ils ne doivent pas essayer de les lancer, pour éviter un plantage.

...possibilité qui n'est, pas, à ma connaissance du moins, offerte par le "standard" de commentaires kernel...

> Un programme ne devrait jamais utiliser pls de 90% de la pile, a mon avis.
Je suis d'accord. Ca évite éventuellement des plantages...

> Ne pas prevoir etre lance d'un shell est une erreur
Là aussi je suis d'accord.

Et si on le lance d'AMS qui fait une sur-consommation de pile ?

Dans quel(s) ca(s) AMS fait-il une surconsommation de pile ? Je vois rarement sp en-dessous de 3D00-3E00 quand on est dans le home screen, mais il doit y avoir quelque chose qui peut le faire consommer plus de pile quand on est dans le home screen, et que je ne connais pas...

-

Ximoon=>Si tu as CC et AS sut ra caltoche, tu peux essayer la même expérience que j'ai faite (c'est comme ca que j'ai compris) :
edite un simplie programme qui alloue des variables dans un bloc en CC:

void main(void){
int a,b=5;
char *c,*d,*e="Ouhhh!";
a=25;
}

et regarde le code AS produit===> le link permet de creer ta zone temporaire de variable.
Enfin, la meilleure facon de comprendre , à mon avis, c'est de tenter ces petites expériences comme je l'ai fait

Essaye ensuite aussi avec des blocs imbriqués, des structures...
Tu vas voir, y'as plein de choses à apprendre!

(Heureusement que Nitro travaille!)

!faqhard Orion_
Pour les erreurs avec l'asm, c'est dû au fait que tu utilises a68k au lieu de GNU as.
Change les (sp,16) ou (a0,1384) en 16(sp) et 1384(sp)

Pour le fait d'ajouter $40000 à ton adresse:
http://tigcc.ticalc.org/doc/faq.html#49

BiHi a écrit :
Pour les erreurs avec l'asm, c'est dû au fait que tu utilises a68k au lieu de GNU as. Change les (sp,16) ou (a0,1384) en 16(sp) et 1384(sp)

Plutôt 1384(a0).

Orion_ a écrit :
et puis

je capte pas trop j'ajoute sa avant ou apres expatch ?

Avant!!!
Et n'oublie pas de rajouter 0x40000 aux deux paramètres de EX_patch, pas seulement au premier, sinon ça recrée le bogue des anciennes versions de ttstart: "Invalid relocation data in ASM program" sous AMS 2.08.

et sa va pas foirer puisque ajouter 0x40000 a l'adrs ou ce trouve le programme
une fois décompressé, sa me parait zarb

Ne cherche pas à comprendre, fais ce qu'on te dit.
Non, franchement, ça marche puisque ce sont 2 adresses qui pointent au même endroit (parce que le matériel ignore les bits en trop lors du déchiffrage de l'adresse). La différence est que la protection anti-exécution traîte les adresses différemment si on ajoute 0x40000 que si on ne l'ajoute pas. Je pourrais expliquer le fonctionnement de cette protection plus en détail, mais je n'ai pas vraiment envie de le faire puisque c'est assez long à expliquer sans omettre des détails importants.

-

EX_patch ne retourne rien, donc a0 ne pointe vers rien d'utile, et donc:
85: jsr (a0) ; GO !!!
est incorrect.

-

>bsr a1

Cette instruction n'existe pas!

Et puis, a1 sera également détruit. Il faut mettre l'adresse dans un registre parmi a2-a6.

-