gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > External data alignment issues

#36069 - KonVex - Mon Feb 14, 2005 8:49 pm

I know that this was brought up before, but haven't found a working solution yet.

I want to link external data into my rom (using the objcopy method).
The problem is that the data isn't 32 Bit aligned, and thus causing all reading operations to return incorrect data.
Is there any way to stop that behaviour?

#36078 - tepples - Mon Feb 14, 2005 9:57 pm

Ever tried the GBFS method or the bin2s method? Both of those, mentioned in the FAQ in the Beginners section, work for me.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#36082 - KonVex - Mon Feb 14, 2005 10:59 pm

Well, I can't use GBFS because I need this info to implement my own FS. :)
I want to include the filesystem image, but the gba refuses to load unaligned data. Appending the imagefile to the rom isn't enough, because that way I wouldn't have a symbol to access my data.

I haven't found bin2s in the faq, but b2x is mentioned in the devrs gba faq (that should be pretty similar). I guess I will try that next.

#36100 - sajiimori - Tue Feb 15, 2005 1:37 am

objcopy always worked for me. :/ Is it possible that your alignment being thrown off by something inside the objects, rather than by the alignment of the objects in the .elf? (nm can tell you that)

#36102 - KonVex - Tue Feb 15, 2005 1:58 am

Here are the symbols generated for my external data:

0200eaad R _binary_ROM_DATA_bin_end
0000c580 A _binary_ROM_DATA_bin_size
0200252d R _binary_ROM_DATA_bin_start

This was compiled using devkitARM R11 as a multiboot rom (but it wasn't working with R8 either).

#36103 - Miked0801 - Tue Feb 15, 2005 2:06 am

Pad your data with 0s to 16/32 bit alignment.

#36115 - sajiimori - Tue Feb 15, 2005 3:58 am

Isn't there some way to tell the linker to align the start of each .o file?

Maybe DevKitAdvance's lnkscript did that for me, because I'm sure my data wasn't coincidentally aligned all the time, and I don't recall having to do it myself.

#36116 - tepples - Tue Feb 15, 2005 4:01 am

Miked0801 wrote:
Pad your data with 0s to 16/32 bit alignment.

"Your data" itself is padded to a multiple of 32 bits in length (size: 0xc580), but the program before it isn't padded to anything bigger than 8-bit. The linker is supposed to pad the program before the data block with 0's to proper alignment, based on an attribute of the data block (called __attribute((aligned(4))) in C or .balign 4 in assembly), but GNU objcopy's man page lists no way to specify such an attribute.

I just use GBFS or bin2s, which handles alignment cleanly. Both are available in the GBFS distribution at my site.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#36164 - KonVex - Tue Feb 15, 2005 3:33 pm

I finally tried bin2s and it works pretty well, the only drawback is that it takes longer to compile now.
Anyway your quick help is really appreciated :)

#36166 - wintermute - Tue Feb 15, 2005 4:08 pm

generate a mapfile and see what's causing the misalignment. The problem is with something before R _binary_ROM_DATA_bin_start.

I've been looking for a method to automatically align objcopied data with little success other than the alignbin shellscript found in the devkitARM bin directory.

#36168 - KonVex - Tue Feb 15, 2005 5:12 pm

I just found something that might be of interest.
If the linked file is called *.all.rodata.o (as suggested in the devrs faq) it is put in rom-space and the start-address is unaligned.
When the all.rodata is left away the data is put into IWRAM, but it is aligned.

Here is a small snippet of the mapfile (with all.rodata and without multiboot):
.rodata 0x0800238c 0xc73c
*(.rodata)
.rodata 0x0800238c 0x6c C:\DOKUME~1\KonVex\LOKALE~1\Temp/ccuAaaaa.o
.rodata 0x080023f8 0xc C:\DOKUME~1\KonVex\LOKALE~1\Temp/ccENaaaa.o
.rodata 0x08002404 0x40 C:\DOKUME~1\KonVex\LOKALE~1\Temp/ccO0aaaa.o
.rodata 0x08002444 0x101 C:/devkitARM/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/interwork\libc.a(ctype_.o)
0x08002444 _ctype_
*all.rodata*(*)
.data 0x08002545 0xc580 ROM_DATA.all.rodata.o
0x0800eac5 _binary_ROM_DATA_bin_end
0x08002545 _binary_ROM_DATA_bin_start
*(.roda)
*(.rodata.*)
*(.gnu.linkonce.r*)
0x0800eac8 . = ALIGN (0x4)
*fill* 0x0800eac5 0x3 ff

#36200 - wintermute - Wed Feb 16, 2005 12:17 am

have a look at the PCXView example in sourceforge

http://cvs.sourceforge.net/viewcvs.py/devkitpro/examples/gba/PCXView/

You're putting the data into a section *after* the const data from the libraries and unfortunately including a constant from libc which is 8 bits. Objcopy puts binaries into the .data section by default. The bin2o macro from my makefiles places it in .rodata