[Kos-dev] Re: [Kos-cvs] [kos] Modification CVS par d2

[d2]

Bonjour,

Une autre petite nouvelle pour ce matin : kos tourne quand on le
compile avec gcc 3.1 (avant ca plantaint a la fin du loader). C'est
parce que, avec gcc 3.1 (en -O2 du moins), de temps en temps les
fonctions static ont leur call remplace par un jmp. Evidemment, quand
on change de pile avant l'appel d'une telle fonction static, ca pete
(les variables locales de la fonction appelee sont sur l'ancienne
pile, et donc tous les adressages 0xfffff4(esp) de la fonction appelee
foirent : ils sortent de la nouvelle pile => triple fault). Suffit
donc de forcer gcc a generer un vrai call.

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@utbm.fr> writes:
    >> => Plus besoin de la relocation a la main des marshalls des
    >> symboles exportes, puisque la relocation a lieu en meme temps
    >> que celle de .init/.load, de facon transparente (comme s'il
    >> s'agissait de code normal).

    Thomas> Pourrais-tu donner un peu plus de precisions en ce qui
    Thomas> concerne ces deux points ? Cela signifie-t-il que le
    Thomas> nombre de relocation que le loader doit effectuer est plus
    Thomas> petit ?

Avant, on recuperait la table des symboles exportes dans une section
speciale, et on faisait une pseudo-relocation rapide au moment de la
generation des marshalls exp_sym et de la recup des
ctors/dtor. Maintenant, on laisse le soin a gcc de generer ces tables
dans les sections .init et .load, ce qui fait que la relocation de
.init et .load va elle meme mettre a jour les tables (faire les
relocations dessus). Reste plus qu'a recuperer ou sont ces tables pour
chaque module : c'est le role des marqueurs "@ctors"... (proteges par
des magic) dans modules.lds, que le loader va regarder (operation
elf32 au doux nom de "setup module tables").

Ca fait que le loader elf32 est plus simple : il y'a une seule
fonction de relocation (appelee une fois pour les symboles locaux, ce
qui met a jour les tables des symboles exportes ; et une 2eme fois pour
faire le linkage des symboles importes), et plus d'arithmetique louche
pour la relocation des champs des marshalls exp_syms, et les
ctors/dtors. Question rapidite, ca doit etre un petit peu plus rapide,
mais ca doit pas changer grand chose (y'a juste le marshall des
exp_syms en moins). Question memoire, c'est idem (le marshall est fait
par le compilo au lieu de par le loader). Question taille du binaire,
on y perd de 4 octets par symbole exporte (cause les symboles exportes
comportent un champ ref_cnt en plus par rapport a avant).

Le point lent, c'est la relocation des symboles extern, et, plus
precisement, la fonction ld_find_expsym_addr() : il faudrait passer
par une table de hachage. Si on choisit d'utiliser kos.elf plutot que
kos.a, evidemment, vu que la relocation est faite par le ld de l'host
(linux, solaris...), bochs charge l'image tres rapidement puisqu'il
n'y a aucune relocation de symboles extern a faire.

Bonne journee,

-- 
d2