#40337 - FeaRog - Sun Apr 17, 2005 6:22 pm
Hi all,
After spending the last few hours wrestling with the linker to get it to do what I want, I figure I'd better give you all a heads up about it.
If you define a lot of global initialized but not read only data, your program will fail, and it will seem to be quite weird crashes. This is because the current linker scripts place initialized but not read only global data into the IWRAM. The limited supply of this means that not all will fit, and accesses to it from your code will result in strange pointers being accessed! Mine were extra strange, in that I found that my pointers to globally defined strings were pointing to other, perfectly valid, globally defined strings. Some came back NULL.
My solution was to modify the link script - I've made it so that all .rodata and .data sections from the object files go into the .text section of the ELF along with the code. This seems to work fine, but I'm sure it won't perform as well.
Anyway, I hope this helps some of you out a bit...
#40340 - Darkain - Sun Apr 17, 2005 6:35 pm
have you tried the link script found at http://ds.darkain.com/hack/ yet?
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40341 - FeaRog - Sun Apr 17, 2005 6:39 pm
Yes, thats what I was using before. The .data section goes into the IWRAM with that script, which is what produces the problem.
#40344 - dovoto - Sun Apr 17, 2005 7:40 pm
Yes i was having that same issue. I ended up moving iwram to ewram memory space to solve it.. your solution is much cleaner. There needs to be a way to get the linker to recognized when it has used all the available ram and have it allocate space elsewhere. Or we should just leave iwram alone and let the user choose what goes in (via IN_IWRAM and CODE_IN_IWRAM).
_________________
www.drunkencoders.com
#40346 - Darkain - Sun Apr 17, 2005 7:45 pm
I would personally prefer to NOT have anything go into IWRAM at all. this is, because, that is where i want to dump the flash cart code. since flash cards can already be read, i plan on throwing a file into the filesystem... something like "flash card driver", and have DarkStar automatically load this into IWRAM, and contain a statically located struct w/ the various file pointers for the main flash card functions. i dont want other things interfearing w/ this code and data. :) this idea is kinda cool really, as it means we could build new flash drivers w/o the need to recompile the entire application.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40348 - DekuTree64 - Sun Apr 17, 2005 8:53 pm
| Darkain wrote: |
| I would personally prefer to NOT have anything go into IWRAM at all. |
I prefer a mix. Linker script support for things that will always be used, like interrupt handling, and then manually copy in bits of code as needed depending on the situation. Those can be done with overlays though, which I haven't tried on DS, but had weird alignment problems on GBA when I tried a long time ago.
For your flash card drivers, I'd suggest just changing the .iwram section start address to leave whatever portion you need unused, and the rest free to be allocated by the linker.
One thing that's been bothering me though... there's only one .iwram section, which is in DTCM according to the crt0, but you can't execute from DTCM. It's only for data.
There's completely seperate ITCM for code. You can store data there too, but it will stall stall one cycle if you execute and load/store from it at the same time (just tested).
Check "CP15 register map" in the programmer's model section of http://www.arm.com/pdfs/DDI0155A_946ES.pdf for how to enable it/ask how big it is/etc.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#40364 - FeaRog - Mon Apr 18, 2005 12:57 am
I think we should clean out the linker script, and make the .data and .rodata go into main RAM. Its probably not the cleanest idea to put it all in .text, because then you can't actually check how much of each you have - it was just my 3am hack solution ;) We should have a .iwram and .ewram section (in fact, I think there already is..) and use __attribute__ to specify any functions (eg interrupt handlers) that we wish to go into these sections. Possibly .itcm and .dtcm sections too. Wrap the clunky __attribute__ things with some nice macros (eg PUT_IN_IWRAM) and we're set for clean, trouble free coding :)
#40369 - tepples - Mon Apr 18, 2005 1:19 am
At least .rodata should go to main RAM to match the behavior of the GBA multiboot link scripts.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#40370 - FeaRog - Mon Apr 18, 2005 1:31 am
.rodata already does - its pretty much straight after .text (I think .fini is in between them, from memory). It was .data that wasn't. So while my strings were in .rodata and hence in main memory, the variables pointing to the strings were in .data, and so were messed up!
#40402 - FeaRog - Mon Apr 18, 2005 6:07 pm
We also seem to be having problems with .bss
Both the arm7 and arm9 put their .bss and stack into the same part of memory, which strikes me as being terribly bad. I got bitten by this one - with a program with such a large amount of data as the one I'm working on I found that the (uninitialized) variable containing the pointer to the file system control memory was (seemingly) randomly changing. It was either the place where this was linked to or the arm7 process was trashing my memory. Anyway, I went nuts with the .text thing and added that too - unfortunately its blown the size of my executable out by 800k! We *really* need to come up with a good resolution for this.
I propose that .data and .rodata go into main memory, and that we rationalize the linker script's handling of the iwram and ewram (making these NOT seemingly magic numbers that depend on sizes of other sections) by perhaps making them their own section, that *nothing* else goes into. I'm not sure about what we should do with .bss. Any ideas?
#40432 - tepples - Mon Apr 18, 2005 9:20 pm
| FeaRog wrote: |
| Anyway, I went nuts with the .text thing and added that too - unfortunately its blown the size of my executable out by 800k! We *really* need to come up with a good resolution for this. |
It could be along the lines of the GBA linker script in devkitARM, which adds a section called .sbss that goes into EWR^H^H^Hmain memory.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#40454 - FeaRog - Mon Apr 18, 2005 11:45 pm
Both the ARM7 & ARM9 attempt to put a .sbss section into main memory.
Its not the .sbss section thats hurting, its the .bss one which appears to automatically place itself at the last VMA referenced in the linker script. This happens to be at something like 0x800000 (plus or minus some zeros), and causes all sorts of weird stuff..
#40480 - wintermute - Tue Apr 19, 2005 9:12 am
does anyone have a decent DS memory map?
The layout on the wiki doesn't seem to be up to date and it's a bit difficult to sort out the linker scripts without knowing which parts are arm9/arm7 exclusive.
#40488 - sasq - Tue Apr 19, 2005 12:04 pm
Everything is exclusive except where it says so. The memory maps seems pretty complete, except you can access parts of VRAM from ARM7 at 0x06000000 if you allocate a bank dor it on the ARM9.