4MB ?

Bon, je dois avoir quelque-chose de foireux dans la configuration de mon système de build avec le dernier devkitarm que j'ai installé: la plupart des outils prennent soudain une taille de 4MiB... avec plein de vide au milieu du fichier ...

Première question, est-ce que ce problème est déjà présent dans le fichier .elf, ou est-ce quelque-chose que j'ai introduit au moment des conversion vers le format .nds ?

J'utilise pour ça l'outil objdump, et il y a déjà quelque-chose de louche: vous voyez ces vaddr et paddr ? l'une est une adresse virtuelle, que les données doivent avoir pour que le programme tourne bien. l'autre... bin c'est la première fois que je vois des valeurs différentes pour ces "adresses physiques"
Et en particulier, une de ces commandes de chargement va utiliser une adresse "physique" 4MiB plus loin que le début de la RAM de la NDS.

Si je croise ces information avec la liste des sections, disponible un peu plus bas, j'ai une correspondance (grâce aux offsets à l'intérieur du fichier ELF) avec une section baptisée ".twl" -- là aussi, c'est une première pour moi. C'est en tout cas bien les bytes qui correspondent à ce qu'on trouve au bout du gouffre du fichier .nds, aux alentours de 4MiB.

Renseignements pris, cette section contient des instructions spécifiques au démarrage pour DSi (et son TW Loader). Une petite mise à jour de mes makefiles pour éviter le passage par un fichier .arm9 (version pré-applatie du contenu du fichier .elf) et c'est réglé: l'outil ndstool qui construit les .nds est maintenant suffisamment évolué pour manipuler lui-même les .elf, comme dit WinterMute.

Et au passage, une simple utilisation de stringstream pour des manipulations de chaînes me coutait 250K dans runMe (qui autrement ne prend "que" 500K).

Voilà qui cloture (enfin) la branche "latest-devkitpro"