the bss section

[bpoint]

Hello all,

I have a few questions regarding the .bss section on GBA, using devkitARM r21:

1) Is there any specific reason why .bss is located in iwram instead of ewram?
2) Is it possible to relocate the .bss section from iwram to ewram? I presume I need to change the gba_cart.ld file, but I'm not exactly sure what I'd need to change and where.
3) Are there any side-effects with moving .bss into ewram? Will its location conflict with malloc() and/or my stack?

Thanks!

[WinterMute]

The decision to use IWRAM for bss was taken long before devkitARM was first released - both the official kit and devkitAdvance had their linkscripts set up like this so basically we followed the crowd for compatibility reasons. Global variables tend to be accessed by more of the code and, in theory, large arrays should be allocated through a memory manager such as malloc.

If you really must allocate a lot of static variables then you can use the secondary bss - libgba headers define EWRAM_BSS for this purpose. Generally I wouldn't advise modifying the linkscripts.

[bpoint]

The decision to use IWRAM for bss was taken long before devkitARM was first released - both the official kit and devkitAdvance had their linkscripts set up like this so basically we followed the crowd for compatibility reasons. Global variables tend to be accessed by more of the code and, in theory, large arrays should be allocated through a memory manager such as malloc.

That sounds reasonable. However, I was hoping to free up IWRAM for more ARM code -- and since malloc() returns a pointer to EWRAM anyway, it seems that data (and bss) would work just fine in EWRAM, granted at a slower speed. But that speed should be easily offset by having ARM code run in IWRAM rather than Thumb from ROM.

...at least, that's what I was thinking.

If you really must allocate a lot of static variables then you can use the secondary bss - libgba headers define EWRAM_BSS for this purpose. Generally I wouldn't advise modifying the linkscripts.

My existing code base is multiplatform, and by using the "static" keyword on a variable, gcc places it in .bss automatically. I'd have to go back through all of my code and tack on the .sbss attribute to each variable, which is something I was hoping to avoid. Not to mention libc and libstdc++ pull in some rather large symbols too, but I am also trying to work towards being to link with -nostdlib, hopefully soon.

If moving .bss and .data into EWRAM doesn't really break anything, I'll take my chances with modifying the link script. I presume all I need to do is just move the .bss and .data sections from the IWRAM area into the EWRAM area? Is there anything else I need to be aware of? Will the existing crt0 still work out of the box?

Thanks!

[WinterMute]

.data is already in ewram.

static controls external visibility and has nothing to do with bss. What determines bss placement is the initialisation of a variable - if it's initialised to 0 or left uninitialised then it goes in the bss section. If it has a non zero initialisation value then it gets placed in .data.

I strongly advise against modifying linkscripts - these have an unfortunate habit of breaking when the toolchain gets updated.

Having said that I'm not averse to changing the default linkscripts - I'm going to have to update them for the next devkitARM iteration anyway due to some changes in the latest linker.

[bpoint]

.data is already in ewram.

My .map file seems to disagree with you:

Code: Select all

.data           0x03004bb4      0x880 load address 0x0810d294
                0x03004bb4                __data_start = <code 342> (.)
 *(.data)
 .data          0x03004bb4        0x4 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/crtbegin.o
                0x03004bb4                __dso_handle
 .data          0x03004bb8        0x4 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/../../../../arm-eabi/lib\libstdc++.a(eh_term_handler.o)
                0x03004bb8                __cxxabiv1::__terminate_handler
 .data          0x03004bbc        0x4 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/../../../../arm-eabi/lib\libstdc++.a(eh_unex_handler.o)
                0x03004bbc                __cxxabiv1::__unexpected_handler
 .data          0x03004bc0      0x418 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/../../../../arm-eabi/lib\libc.a(lib_a-impure.o)
                0x03004bc0                _impure_ptr
 .data          0x03004fd8      0x410 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/../../../../arm-eabi/lib\libc.a(lib_a-mallocr.o)
                0x030053e4                __malloc_sbrk_base
                0x03004fd8                __malloc_av_
                0x030053e0                __malloc_trim_threshold
 .data          0x030053e8       0x44 c:/devel/devkitarm/bin/../lib/gcc/arm-eabi/4.1.2/../../../../arm-eabi/lib\libsysbase.a(iosupport.o)
                0x030053e8                devoptab_list

I should probably also mention that my .map file shows that absolutely nothing is being put into EWRAM (well, aside from the empty .sbss section):

Code: Select all

                0x02000000                __ewram_start = 0x2000000

.ewram          0x02000000        0x0 load address 0x0810db5c
 *(.ewram)
                0x02000000                . = ALIGN (0x4)
                0x0810db5c                __pad_lma = (__ewram_lma + SIZEOF (.ewram))

.sbss           0x02000000        0x0
                0x02000000                __sbss_start = <code 342> (.)
 *(.sbss)
                0x02000000                . = ALIGN (0x4)
                0x02000000                __sbss_end = <code 342> (.)
                0x02000000                __ewram_end = __sbss_end
                0x02000000                __eheap_start = __sbss_end
                0x02000000                __end__ = __sbss_end

And, if I understand the linker scripts properly, gba_cart.ld looks like it's putting lots of stuff in IWRAM:

Code: Select all

	.data ALIGN(4) : AT (__data_lma)
	{
		__data_start = ABSOLUTE(.);
		*(.data)
		*(.data.*)
		*(.gnu.linkonce.d*)
		CONSTRUCTORS
		. = ALIGN(4);
	} >iwram = 0xff

...along with the init/fini array as well. Do these really need to be in IWRAM?

static controls external visibility and has nothing to do with bss. What determines bss placement is the initialisation of a variable - if it's initialised to 0 or left uninitialised then it goes in the bss section. If it has a non zero initialisation value then it gets placed in .data.

Right, I understand that. What I was saying is it is difficult for me to go back through all of my code and append the .sbss section attribute onto every symbol that is being put into .bss (and hence, IWRAM). Which is why I was hoping I could just easily move them out into EWRAM.

Having said that I'm not averse to changing the default linkscripts - I'm going to have to update them for the next devkitARM iteration anyway due to some changes in the latest linker.

I understand. Unfortunately I don't see any other way of freeing up space in IWRAM to allow more code to be placed there instead of in ROM...

[WinterMute]

.data is already in ewram.

My .map file seems to disagree with you:

Heh, that's what I get for relying on memory & not going back to check the linkscripts before responding.

Actually .data probably would be better off in ewram instead. I'm not so sure about bss, it really depends on how people have written things like mod players where ram speed can be a major factor.