devkitPro

I'm trying to port GSM Player from devkitARM circa R21, which is no longer available, to current devkitARM. The problem I'm running into is that the linker is no longer placing gsmcode.iwram.c in IWRAM. Instead, it is placed in ROM and running from ROM. I can tell because grep gsm_decode .map shows its address as 0x00000000080013fc

My source code: https://github.com/pinobatch/gsmplayer-gba

Note: I am using a modified makefile for three reasons. The first is to specify options to grit for converting the font. The second is to choose to compile only a subset of source files, as opposed to relying on wildcard matching to always compile all source files in a given directory. The third is so that Make shows the exact command line used to compile each source file, as opposed to only seeing the filename. Is use of the standard makefile a condition of receiving support?

With the help of someone else, I managed to work around it by adding __attribute__((section(".iwram"))) before the definition of every function in the file. This produced a working copy of GSM Player with the same functionality as the 2004 version. Will setting the section per function, as opposed to per file, be the way forward for devkitARM?

There was a small issue in the GBA linker script that prevented .iwram.c files from working; it has been solved recently. You can grab the latest updates by doing pacman -Syu.

Also for your information, there are official channels through which we give support and advice for devkitPro toolchains.

PinoBatch wrote: ↑Sat May 04, 2019 2:09 pm I'm trying to port GSM Player from devkitARM circa R21, which is no longer available, to current devkitARM. The problem I'm running into is that the linker is no longer placing gsmcode.iwram.c in IWRAM. Instead, it is placed in ROM and running from ROM. I can tell because grep gsm_decode .map shows its address as 0x00000000080013fc

This issue was fixed a while ago although the relevant package was only updated this morning. Update your tools - you can open msys2 shell & run pacman -Syu.

Note: I am using a modified makefile for three reasons. The first is to specify options to grit for converting the font.

You don't need to replace the Makefile to do this. Adding a rule would do the job. The simplest one can be found in the nds examples at https://github.com/devkitPro/nds-exampl ... #L151-L159 which should work well enough.

The second is to choose to compile only a subset of source files, as opposed to relying on wildcard matching to always compile all source files in a given directory.

This is easy to do and doesn't require replacing the Makefile, it's possible to just replace the wildcard rules with the list of source files you want to compile.

The third is so that Make shows the exact command line used to compile each source file, as opposed to only seeing the filename.

The standard rules already do that.

Is use of the standard makefile a condition of receiving support?

Modifying a standard Makefile is one thing. Replacing the entire Makefile is something we'd rather discourage, especially when the replacement Makefile doesn't work in the same way and requires modifying a stock toolchain install in order to function. There are several issues with your replacement, not least the use of absolute paths to standard tools which then change for no reason based on the host OS. Something we've worked very hard to do is to ensure that our standard templates work exactly the same way whether the user is running Windows, macOS or Linux.

I'll try and take some time and rejig a standard Makefile for you. In the meantime please don't follow advice from people not directly associated with devkitPro. Such advice is almost invariably inappropriate bodgery.

PinoBatch wrote: ↑Sat May 04, 2019 8:51 pm With the help of someone else, I managed to work around it by adding __attribute__((section(".iwram"))) before the definition of every function in the file. This produced a working copy of GSM Player with the same functionality as the 2004 version. Will setting the section per function, as opposed to per file, be the way forward for devkitARM?

Absolutely not, we came up with this tagging in the first place to avoid exactly that. Not entirely sure when it broke but it's fixed now.

This uses a standard Makefile with roughly the set of changes I mentioned https://github.com/pinobatch/gsmplayer- ... tandardise

I can PR that for you to merge if you like.


Something that particularly concerns me with your current makefile is this https://github.com/pinobatch/gsmplayer- ... le#L62-L63 which would suggest that you've obtained devkitpro supplied files from elsewhere and installed them manually inside the devkitARM folder. These are installed via pacman and exist in exactly the same place on all platforms you shouldn't be adding anything inside the devkitPro folder at all. Things like this propagate and end up with particularly difficult problems to track down when people experience issues with mismatched tool versions. Please don't do this.

Merged. Thank you.

I think half of the problem with calling the tools from the wrong folder was that I originally installed devkitARM using devkitPro Updater about a week before the May 2018 kitchen sink update split gba-tools out from devkitARM. I mistook a difference between a Windows build from before this update and a Linux build from after this update for a difference between the Windows build and the Linux build.

Now reminding myself to fix 160p Test Suite the same way using .grit files.