gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > gba_mb.specs bug (was Reporting a bug w/o SF.net)

#145018 - tepples - Sat Nov 10, 2007 3:19 pm

Reporting a bug if I can't log in to SourceForge.net?

I have discovered what might be a defect in devkitARM R21. I have written a detailed description of the behaviors that I have observed when running a libgba example, but Mighty Max and wintermute said that maintainers don't read forums, so I won't paste it here. But the devkitPro project's bug tracker does not take anonymous submissions. I tried to log in to SourceForge.net using the user name that I had used before, but it would not take my password. So I requested a password reset. It has been 16 hours, and the confirmation e-mail message has not yet arrived in my inbox nor in my junk mail folder. What is the next step in trying to report a problem with devkitARM or another devkitPro project?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Last edited by tepples on Sat Nov 24, 2007 6:14 pm; edited 1 time in total

#145020 - Mighty Max - Sat Nov 10, 2007 3:45 pm

How about directly addressing the maintainer(s) ?
_________________
GBAMP Multiboot

#145036 - tepples - Sat Nov 10, 2007 8:25 pm

Mighty Max wrote:
How about directly addressing the maintainer(s) ?

I got in touch with wintermute on blitzed#gbadev. It was a problem with the GBA link script, where a program would work as .mb but not as .gba. Wintermute came up with a one line fix to .../devkitARM/arm-eabi/lib/gba_mb.ld, changing this:
Code:
__ewram_overlay_end = ABSOLUTE(.);

to this:
Code:
__ewram_overlay_end = __load_stop_ewram9;

He suggested that this solution isn't perfect, but at least it worked for me.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#145052 - Cearn - Sun Nov 11, 2007 1:17 am

The root of the problem is that __end__ (which is tied to __ewram_overlay_end) ends up as an iwram address, rather than an ewram address, causing the copy from 'rom' to ewram in ctr0.s to go wrong. It seems that the linker doesn't like ABSOLUTE(.) outside of a section definition if that section is empty; it looks like it just takes the end location of the last non-empty section.

For example, there is this for the sbss section:
Code:
// line 234-ish
   .sbss ALIGN(4):
    {
      __sbss_start = ABSOLUTE(.);
      *(.sbss)
      . = ALIGN(4);
      __sbss_end  = ABSOLUTE(.);
   }

With a near-blank multiboot project, the __sbss_end is inside ewram where it belongs. However, if I move the __sbss_end line outside the braces (which is where _ewram_overlay_end is found as well), __sbss_end has shifted to iwram.

But if I then add anything to sbss or ewram manually, like so:
Code:
EWRAM_DATA u8 foo;
// or
EWRAM_SBB u8 bar;

Both sbss and ewram ends are where they're supposed to be.

I know this doesn't solve the problem, but maybe it'll help figure out what's going on. It does suggest a workaround that doesn't rely on messing with the linkscripts yourself: put a dummy variable in ewram.