#11377 - DekuTree64 - Fri Oct 03, 2003 7:10 pm
I've been having problems with this for the longest time. How do you get things into the .rodata section in ASM?
.section rodata
compiles and links just fine, but I checked in the map file and all my C const data is in .rodata, and rodata seems to start at address 0, instead of somewhere in ROM, and therefore doesn't work.
.section .rodata
compiles, but when linking says it overlaps .iwram at 0x8000000-something, which makes no sense, because .iwram is at 0x3000000.
Is there something I'm missing or what? I can put data in the text section and it works fine, but that just doesn't seem quite proper.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#11389 - regularkid - Sat Oct 04, 2003 2:10 am
hmmm. I have the latest crt0.o and lnkscript from gbadevrs and all my code by default gets put into the .rodata. However, I'm not sure about variables declared in ASM (I always create variables in C code). That is really strange about the compiler screwing up and making .rodata at address 0. Maybe try grabbing the latest crt0.o and lnkscript.
_________________
- RegularKid
#11391 - DekuTree64 - Sat Oct 04, 2003 3:01 am
Well, I discovered that it only says it overlaps with .iwram if you put an .align 4 after the .section .rodata, so it works now. I'm not sure if it's quite safe not to align things specifically, but it seems to be fine. The weird thing is .align alone (which I think aligns to 4 bytes) and .align 2 are fine, but .align 4 causes linker problems.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#11397 - tom - Sat Oct 04, 2003 10:45 am
be careful with .align, btw:
from the gas docs:
| Quote: |
The way the required alignment is specified varies from system to system. For the a29k, hppa, m68k, m88k, w65, sparc, and Hitachi SH, and i386 using ELF format, the first expression is the alignment request in bytes. For example `.align 8' advances the location counter until it is a multiple of 8. If the location counter is already a multiple of 8, no change is needed.
For other systems, including the i386 using a.out format, it is the number of low-order zero bits the location counter must have after advancement. For example `.align 3' advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.
This inconsistency is due to the different behaviors of the various native assemblers for these systems which GAS must emulate. GAS also provides .balign and .p2align directives, described later, which have a consistent behavior across all architectures (but are specific to GAS).
|
for the arm cpu the 2nd method is used, so .align 4 aligns to a 16 byte boundary, not to a 4 byte boundary. personally i always use .balign, since from other assemblers i'm used to specify alignment in bytes and not in number of low order bits to set to zero, but this is really just personal taste.