Source file paths in elf file are incorrect.

[luckytyphlosion]

If -g is enabled where the C files are compiled, the resulting elf will have source file lines added (example added below).
@$(PREPROC) $(C_BUILDDIR)/$*.i charmap.txt | $(CC1) $(CFLAGS) -g -o $(C_BUILDDIR)/$*.s

no$gba will then inline the source within the disassembler. However, it seems that the path to the source files within the elf is incorrect, as only the line number and file are output in no$gba's debugger.

Copying source files into the same directory as the elf solves the issue, and source lines are printed. What is likely the case is that the src/ path is not included within the filename. To fix this, it would require fixing the Makefile, but I'm not an expert at Makefiles and I don't know the design decisions behind the current Makefile either.

[luckytyphlosion]

It turns out that this is actually an issue with msys2 and WSL, but NOT with Cygwin. It also might be an issue with no$gba.

In the output asm file with debugging enabled, we can find an ascii line corresponding to the path where pokeemerald is built. Below is the line between WSL, msys2, and Cygwin.

• WSL: .ascii "/mnt/c/users/user/documents/github/pokeemerald\000"
• msys2: .ascii "/home/User/documents/github/pokeemerald\000"
• Cygwin: .ascii "/cygdrive/c/users/user/documents/github/pokeemerald\000"

Another thing which is relevant: The line above is .ascii "src/palette.c\000" (sample file)

no$gba is able to evaluate the path when pokeemerald is built with Cygwin, but NOT with msys2 and WSL. I modified agbcc to replace /mnt/ with /cygdrive/, which fixed the issue on WSL. My theory as to how no$gba finds the files is that it'll concatenate the compilation path and the source file path, and look for the file of the resulting path. Somehow, no$gba is able to detect and remove /cygdrive/. I don't know the decision process for if the file doesn't exist, but apparently it just looks for if the file is in the same directory as the elf file (weirdly enough, it doesn't look using the source file path, e.g. looking for src/palette.c itself).

This will likely require a combination of fixing agbcc AND passing a flag within the Makefile to agbcc specifying the terminal used so that agbcc will know how to patch the compilation path.

[aplumafreak500]

What about if eg. the repo is built on Linux or macOS and then transferred to no$GBA (or if no$GBA is ran under Wine)? I imagine the scenario is similar to the above, anyways, but still worth pointing out.

There's also building with MODERN=1 to take into account.

Perhaps this should be taken up with the dev of No$GBA in my opinion.

[luckytyphlosion]

What about if eg. the repo is built on Linux or macOS and then transferred to no$GBA (or if no$GBA is ran under Wine)? I imagine the scenario is similar to the above, anyways, but still worth pointing out.

Then I guess you're screwed. I'm actually not sure if no$gba even runs in Wine, and I don't know how no$gba handles filepaths in those instances.

Contacting Korth (no$gba dev) is a possibility, but I seriously doubt that he has the time and/or interest to fix it given that no$gba has far greater usability issues that haven't been fixed. Looking through the backlogs, Normmatt has mentioned that Korth is working on 3DS support so I wouldn't get my hopes up.

[aaaaaa123456789]

Contacting Korth (no$gba dev) is a possibility, but I seriously doubt that he has the time and/or interest to fix it given that no$gba has far greater usability issues that haven't been fixed. Looking through the backlogs, Normmatt has mentioned that Korth is working on 3DS support so I wouldn't get my hopes up.

I doubt there is much to fix. A much better idea would be to ask about the behavior of the debugger, because it's clear that we don't know how it works and how it finds files.

[rawr51919]

Are there any other debuggers that exhibit similar behavior to no$gba in terms of the source file paths?