Page 1 of 1
the bss section
Posted: Sat Jan 12, 2008 10:00 am
by 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!
Re: the bss section
Posted: Mon Jan 21, 2008 1:17 am
by 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.
Re: the bss section
Posted: Mon Jan 21, 2008 7:39 am
by bpoint
WinterMute wrote: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.
WinterMute wrote: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!
Re: the bss section
Posted: Tue Jan 22, 2008 3:28 am
by 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.
Re: the bss section
Posted: Tue Jan 22, 2008 11:39 am
by bpoint
WinterMute wrote:.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?
WinterMute wrote: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.
WinterMute wrote: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...
Re: the bss section
Posted: Sat Jan 26, 2008 2:42 pm
by WinterMute
bpoint wrote:WinterMute wrote:.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.