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"

Wformat-truncation

Pretty impressive new feature of gcc/g++ available in the latest devkitarm.
Look at that.

MapWindow.cxx:377:23: warning: %i directive output may be truncated writing 

    between 1 and 2 bytes into a region of size between 0 and 9 [-Wformat-truncation]
snprintf(msg, 32, "@%i,%i : %s [%ix%i]",xpos, ypos, why,
                   ^~~~~~~~~~~~~~~~~~~~~
MapWindow.cxx:689:12:      report("editing meta-layer");
                                  ~~~~~~~~~~~~~~~~~~~~
MapWindow.cxx:377:23: note: directive argument in the range [8, 16] 

MapWindow.cxx:377:23: note: directive argument in the range [8, 16]
 note: 'snprintf' output between 32 and 42 bytes into a destination of size 32

- gcc detected that I'm calling that snprintf function with a value of 'why' that is actually the "editing meta-layer" string, which is 18 bytes long
- it understood that this and some numbers had to fit within 32-bytes output
- the format characters only take 9 bytes
- xpos and ypos are 16-bit values, needing at most 5 characters to be rendered on-screen
- 18 + 9 + 4 = 31. that's the case where all the numbers take only 1 byte. We have barely enough room to display the message (and its terminating zero character)
- 18 + 9 + 5 + 5 + 2 + 2 = 41. That's the case where we have all numbers using their maximum size. Note that GCC/G++ could guess that we'll only use numbers between 8 and 16 by looking at  blockop?16:8 argument!

Having such thing can be super precious when you know what's going on and want to harden your software. Hopefully, there is no overflow expected here. Only truncation. And since the purpose is to put a message on a 32-bytes wide line, I'm fine with truncation here. I'll have to tell that to the compiler the best possible way with some #pragma.

edit: oh, actually the compiler is even smarter than I thought: it can tell whether you checked for the return value and won't bother you if you handled truncation with an if (needed > sizeof(msg) - 1)

If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating NUL byte)  which would have been written to the final string if enough space had been available.

Oh, and by the way,

*snprintf() write at most size bytes (including the terminating null byte) to str.

So in my code where I want 32 characters on the 32-char-wide screen, I should have a 33-bytes buffer and pass 33 to snprintf.

Another devkitpro update

Another laptop update ... The previous one started to act pretty weird regarding AC power. I survived a couple of week with the old (2007) laptop, enjoyed the music collection it has and the larger screen. This one is more similar to the faulty one with a 1350x768 screen, but it has SSD.

Well, it was also the opportunity to try dsgametools with the latest devkitpro. And it was pretty disturbing. At first, you now have to install a package manager first before you install what you need. It could have been done with a custom apt-get setup but they opted for pacman with a binary package you have to pre-install from their github. Not really the way I believe open source should work ...

Pour bien démarrer le développement homebrew, que ce soit sur NDS ou GBA, une seule addresse: devkitpro.org. La procédure d'installation a pas mal bougé depuis la dernière fois, par contre. L'équipe de Wintermute est passé à un dépôt pacman (pour "PACket MANager", hein. Toute ressemblance avec une pizza au citron n'est que clin d'oeil de geek), avec la nécessité de télécharger leur version binaire de pacman (pourtant un outil fréquent dans les distributions linux) avant de continuer.

Les utilisateurs windows auront peut-être une expérience plus proche de leurs habitudes avec l'installateur .exe ... Un peu déboussolant pour un vieux briscard de sourceforge, mais j'ai fini par en venir à bout et mon laptop tournant un ubuntu bionic LTS 2018 est maintenant prêt à me râler dessus vu que les réglages par défaut de g++ 8 n'ont pas grand-chose à voir avec ce à quoi mon code était habitué.

I'll keep the new error messages and improved warnings of g++ 8.1.0 for another post. Here, I missed some headers or other stuff to rebuild everything

• errno definition for dswifi ... that is likely an old one. manually installing sgIP_errno.h apparently fixed things. I'd prefer to get the sources of current dswifi to ensure everything is fine. Hope I'll find them.
• load_bin,load_bin_size as well as bootstub_bin, bootstub_bin_size (for nds_loader_arm9, used in runME and self-upgrade features) are missing. Iirc, they should be built from .bin files ... They are still in libppp9/data ... I'll have to find out why they were not processed.
• there's a weird warning about __sync_synchronize() which is invoked when I have a static object. I have a workaround, but I really wonder why they introduced that in newlib...