Cela fait quelques semaines que je réfléchis à l'idée aussi. Je ne suis pas du tout expert dans ce domaine, mais j'ai l'impression que la voie de l'exécutable PIC/PIE est très séduisante, mais aussi assez complexe. Il me semble aussi que la newlib n'est pas vraiment adaptée à ce fonctionnement (même en la recompilant correctement). J'ai par contre bien aimé l'idée du tar comme étant le support du "système de ficher" flash.
Du coup, je suis parti sur l'idée de générer un elf linké partiellement (donc avec le plus gros du travail de fait, et juste quelques relocations à gérer), et de faire le link final au moment d'ajouter le binaire au tar. C'est dommage car cela requiert d'avoir un linker sous la main, mais ça reste très rapide et je suppose qu'on doit pouvoir faire assez facilement un outil javascript pour faire ça directement depuis une page web (et couplé avec webdfu, ça serait parfait).
Au final, ça fonctionne plutôt bien, j'ai porté KhiCAS dans ce "mode" sans trop de souci (mais je bute un peu sur la simplification/normalisation de son interaction avec epsilon, du coup j'ai repris l'api actuelle telle que).
Je suis resté assez "terre à terre" pour la communication app externe/epsilon. Le point d'entrée de l'app externe reçoit un tableau de pointeurs des points d'entrée de l'API, et une zone mémoire lui servant de heap. Les sections data et bss sont alloués statiquement en bas de la pile et réinitialisées entre chaque lancement. Chaque application embarque sa libc, et son malloc qui va utiliser le heap pré-alloué. Ça permet de repartir avec un heap propre à chaque lancement, mais pour l'instant aucun état n'est sauvegardé (sauf pour KhiCAS qui utilise le script store).
Les dépôts sont disponibles ici (epsilon/delta avec launcher, et le "builder" de tar):
https://github.com/Delta-NumWorks/delta/tree/externalhttps://github.com/Delta-NumWorks/external-apps
Posté: 13 Sep 2019, 18:07
Et 