#12840 - poslundc - Fri Nov 28, 2003 6:21 pm
How do I tell from the .map file where in memory my code is being copied to when the GBA loads up?
When I use .section .iwram, I can see the the function name being referenced with a ROM address (0x08XXXXXX), but I can't figure out how to tell that it is placed in iwram later on.
My main reason for asking is that I've tried adding .section .rodata before my Thumb function to make sure it is being run from the ROM, but it mysteriously crashes the app. Does that indicate that it wasn't running from ROM by default, for some reason? And moving it there made it stop working...?
Thanks,
Dan.
#12845 - tepples - Fri Nov 28, 2003 7:17 pm
| poslundc wrote: |
| How do I tell from the .map file where in memory my code is being copied to when the GBA loads up? |
I don't know; I don't use .map files. But you can extract such information from .elf files:
nm shooter.elf
list the run addresses of code and data objects in shooter.elf, ordered by name
nm -n shooter.elf
list the run addresses of code and data objects in shooter.elf, ordered by address
| Quote: |
| My main reason for asking is that I've tried adding .section .rodata before my Thumb function to make sure it is being run from the ROM |
You should place your functions in section .text. The DevKit Advance link script will always place .text section in ROM unless you're compiling for multiboot, in which case it will be placed in EWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#12851 - poslundc - Fri Nov 28, 2003 8:50 pm
Thanks, tepples. Is there a link to somewhere that I can go to learn more about .section locations, etc.? Everything I've found seems to be either erroneous or incomplete.
Thanks,
Dan.
#12852 - poslundc - Fri Nov 28, 2003 9:05 pm
Ack! According to nm, all of my ARM routines are currently being called from addresses in the 0x08000000 range! They must be going ridiculously slow if they're running from ROM instead of IWRAM.
What could possibly be the reason for this? I've put .section .iwram at the beginning of each of those.
Thanks,
Dan.
#12853 - DekuTree64 - Fri Nov 28, 2003 9:12 pm
Hmm, my .map files seem to show .iwram functions in .iwram, but not the locations in ROM that they're copied from. Are you sure your function is actually geting put in IWRAM? One easy way to check is to put an infinite loop in the function, open it in VBA, it of course locks up, then check the disassembly and see if you're in 0x3000000 or 0x8000000.
If you're just using
.section .iwram
try
.section .iwram, "ax", %progbits
instead, and see if that fixes it. GCC seems to be pretty hard to talk into working properly with different sections. I got so fed up with it when making my demo for the compo that I just started declaring big arrays in my functions, copying the code I needed into them, and branching to the array address. Since arrays go onto the stack, and the stack is in IWRAM, it worked fine.
And yes, use .text for code, .rodata for read-only data. I don't know if it has any specific rules about not putting functions in .rodata, but one interesting thing I discovered when trying to put my big chunks of data in .s files is that if you use .align 4 while you're in .rodata, it causes weird errors about .rodata overlapping with .iwram or something. .align 2 is fine though, and that always seems to get it word aligned, even though I thought it meant align to 2 bytes. I guess it means align to 2 words, in which case .align 4 is wasting space anyway. Took me forever to figure out that's what was causing the errors.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#12854 - poslundc - Fri Nov 28, 2003 9:44 pm
Changing it to .section .iwram, "ax", %progbits doesn't seem to make any difference. I tried .section .data as well, all to no avail.
This all seems very ridiculous to me. Does anyone know where I can get the latest crt0.s and linkscript files? Maybe that has something to do with it...
Thanks,
Dan.
#12856 - poslundc - Fri Nov 28, 2003 11:12 pm
Aha! Apparently it was because I was using a .text directive after the .arm directive. Not sure why that was there... it must've been in the tutorials when I first learned ARM asm.
Dan.
#12867 - DekuTree64 - Sat Nov 29, 2003 1:23 am
Ah, that makes sense. So you were doing something like this?
.section .iwram
.arm
.align
.text
label:
@do stuff
.text is short for .section .text, so that would be going back to putting code in ROM just before starting to actually write stuff.
Oh well, at least the mystery is solved.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#12873 - tepples - Sat Nov 29, 2003 4:59 am
| DekuTree64 wrote: |
| one interesting thing I discovered when trying to put my big chunks of data in .s files is that if you use .align 4 while you're in .rodata, it causes weird errors about .rodata overlapping with .iwram or something. .align 2 is fine though, and that always seems to get it word aligned, even though I thought it meant align to 2 bytes. I guess it means align to 2 words, in which case .align 4 is wasting space anyway. |
On some platforms, .align n aligns to n bytes. On other platforms, .align n aligns to 2^n bytes. Gas matches the behavior of the platform's vendor-supplied assembler. To force .align to do what you want, use the Gas directive .balign which always aligns to n bytes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.