Source file paths in elf file are incorrect. about pokeemerald HOT 5 OPEN

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.

from pokeemerald.

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.

from pokeemerald.

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.

from pokeemerald.

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.

from pokeemerald.

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

from pokeemerald.