PreOS 0.70 - Page 4

Autorises-tu les libraries ?
Je sens que ca va etre chiant cette extension...
C'est pour ca que je te proposais de faire une lib que tu mets complete en TSR
(Tu peux la reloger facilement et la table d'exportation est deja faite).
En + tu peux la compresser avec ton programme.

Tu voudrais:
short kernel::RelocPartialProgram (void *program, void *dest, bool reloc_mode, bool allow_lib, unsigned long begin, unsigned long end) ?

dans mon idée, les libs dynamiques se trouveraient divisées en 2 catégories : les libs dynamiques standard et les libs dynamiques TSR (dont le nom pourrait commencer par un 0, par exemple, pour qu'elles ne soient jamais trouvées par les kernels ne connaissant pas le format)
et le format 68kL est trop compliqué à mon goût et inadapté à des TSR : la table de relogement/RAM_CALL/ROM_CALL/bss/importation ne sert qu'une fois, à l'installation ; si on la garde, ça fait de la place perdue

>et le format 68kL est trop compliqué à mon goût et inadapté à des TSR : la table de relogement/RAM_CALL/ROM_CALL/bss/importation ne sert qu'une fois, à l'installation ; si on la garde, ça fait de la place perdue
Le kernel peut l'enlever (D'ailleurs c'est en projet).

ça serait quoi, le reloc_mode ? pour reloger/supprimer le relogement ?
sinon, le *dest, mouais. Disons qu'il pointera vers n'importe quoi

petit schéma :

[ ****** | ****** | ****** ]    -> programme 68kP d'origine
<- *program pointe ici

|        [ ****** ]          -> morceau recopié en RAM
<- *dest pointe ici

Le kernel peut l'enlever (D'ailleurs c'est en projet).

comment ça ?

Et que dis-tu de:

Reloc2 (void *src, void *dest, void *code, void *lower, void *upper, bool mode);

avec:
+ src: Le code a patcher (Lecture des offsets).
+ dest: Ou reloger.
+ code: addresse de debut de la section (Peut etre different de dest).
+ lower: Addresse minimale
+ upper: Addresse maximale.

Un programme kernel serait relogee par:
Reloc2(src, src, src, src, src+65536, RELOC_MODE);
?

> sinon, le *dest, mouais. Disons qu'il pointera vers n'importe quo
Oui

ça sert à quoi le booléen ?
je ne vois pas bien la différence entre dest et code

src est l'endroit ou on lit les offset.
dest est l'endroit ou on patche le code de section
code est l'endroit de debut de la section.

Ca me servira pour les FlashApps (qui doivent etre reloger en RAM avant d'etre envoye ne ROM).

bon bah ça me va alors

Je sais pas si je le ferais

Un kernel::RestorerVector ? non?
Sinon les TSR kernel sa pourrais me servir pour TIM, si je trouve le courage de m'y remettre cet été

Explicite ce que tu veux.

Pour PreOS fait bien une sauvegarde de la table des vecteur non? un RestorerVector(numero_de_vecteur) ca éviterait au programmeur fénéant de faire une sauvegarde lui même
Si je dis une connerie désolé je me suis jamais penché de près vur les vecteurs.

PpHd
: kernel::GHOST_SPACE (Macro comme ROM_BASE) : Ecriture partout (ie dans les vecteurs).

Niet! Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager! Que feras-tu si le prochain modèle n'a plus du tout de ghost space?

Et Flanker, je ne comprends pas pourquoi tu t'obstines à vouloir faire un TSR en kernel! Le _nostub est beaucoup plus adapté!

alors la RC2 ca sear kan ??

Le _nostub est beaucoup plus adapté!

Et comment tu peux le savoir ? Si je le fais, c'est qu'il y a des raisons

Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager!

[troll]d'ailleurs, c'est celle qui a toujours été prônée par la tigcc team[/troll] j'ai toujours utilisé cette méthode, personnellement.
je suis à peu près d'accord avec toi. (cf. plus bas)

Que feras-tu si le prochain modèle n'a plus du tout de ghost space?

il fera bclr.b #2,$600001 (j'ai déjà soulevé cet argument)

cerede > quand elle sortira

./105: Je ne comprends pas ce que tu veux. Regarde bien ce que fais RegisterVector. Il enregistre un vecteur dans la copie interne de PreOS.
Je me demande d'ailleurs s'il doit aussi l'activer (ie le copier dans les vecteurs reels ?).

>Niet! Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager!
>Que feras-tu si le prochain modèle n'a plus du tout de ghost space?
Tu crois que je n'y ai pas pense ?
J'ai le choix entre:
+ Executer le programme entierement avec la protection ecriture desactive.
+ Mettre ghost space a une adresse impaire et intercepter les adress error.
+ Intercepter les stack overflow et les reinterpreter correctement.


./107: When it's done, of course !

qu'en sera-t-il de ma proposition pour les libs-TSR ? ça permettrait aux programmes kernels standards de les utiliser également, non ?

Il faut que tu revoies ta methode pour clarifier clairement ce que doit faire tsrlib.

                                Liens?          Liens?
INSTALLEUR TSR   <--> TSRLIB <--> Preos

( Ensuite, pour l'utilité, euh.... )

De quoi tu parles ?

PpHd :
>Niet! Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager!
>Que feras-tu si le prochain modèle n'a plus du tout de ghost space?
Tu crois que je n'y ai pas pense ?
J'ai le choix entre:
+ Executer le programme entierement avec la protection ecriture desactive.
+ Mettre ghost space a une adresse impaire et intercepter les adress error.
+ Intercepter les stack overflow et les reinterpreter correctement.

Euh, ton enthousiasme me paraît un peu exagéré... C'est très loin d'être trivial de faire un truc qui intercepte tout ça :
* le PC est mis à la position qu'il aurait dans l'instruction suivante, et pas à la position de l'instruction précédente, donc c'est pas vraiment viable de désassembler l'instruction courante (et accessoirement, c'est plutôt difficile)
* au cas où tu voudrais faire dans les solutions gores, tu ne peux pas imposer au programme appelant d'utiliser ton adresse uniquement comme adresse absolue et de ne pas la stocker pour un usage ultérieur... comment gérer

 lea ghost_space+42,a0
 move.l a0,my_ghost
 ...
 move.l my_ghost,a1
 lea 8(a1),a2
 addq.l #2,(a2)

?

Ce n'est même pas que ce serait long/gros de faire un désassembleur (même si ça l'est), mais c'est même théoriquement impossible de détecter de manière non-ambiguë quelle était l'instruction précédente...

Pour le coup, Kevin a raison et il faudrait utiliser le port I/O pour désactiver temporairement la protection.

 lea ghost_space+42,a0 
 move.l a0,my_ghost 
 ... 
 move.l my_ghost,a1 
 lea 8(a1),a2 
 addq.l #2,(a2)

Tu as lu la doc de kernel::GHOST_SPACE ? Non, donc tu sais pas que ce code n'est pas autorise.

PpHd :
>Niet! Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager!
>Que feras-tu si le prochain modèle n'a plus du tout de ghost space?
Tu crois que je n'y ai pas pense ?
J'ai le choix entre:
+ Executer le programme entierement avec la protection ecriture desactive.
+ Mettre ghost space a une adresse impaire et intercepter les adress error.
+ Intercepter les stack overflow et les reinterpreter correctement.

Ce n'est pas super propre quand même
Surtout la 1...

PpHd :

 lea ghost_space+42,a0 
 move.l a0,my_ghost 
 ... 
 move.l my_ghost,a1 
 lea 8(a1),a2 
 addq.l #2,(a2)

Tu as lu la doc de kernel::GHOST_SPACE ? Non, donc tu sais pas que ce code n'est pas autorise.

OK, donc inutilisable en C

Mais si vous voulez pas vous en servir, ne vous en servez pas !
On croirait que j'impose son utilisation.

#mac#

 lea ghost_space+42,a0  
 move.l a0,my_ghost  
 ...  
 move.l my_ghost,a1  
 lea 8(a1),a2  
 addq.l #2,(a2) 

Mais oui! Tu as raison. Ca c'est du code C genere pour ecrire dans un vecteur !

#define set_vector(n,ptr) *((volatile unsigned long *)((unsigned long) n + (unsigned long) &GHOST_SPACE)) = ((unsigned long) ptr)

Ca c'est du code C normal pour mettre a jour un vecteur. J'attend avec impatience ta reponse. Je la connais.