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 > A bug or am I just stupid?

#30365 - Mucca - Tue Nov 30, 2004 7:35 pm

My c++ source looks essentially like this:

Code:
constructor( mystruct * header){
    this->width = header->width;
    .
    .
    .
}


which essentially compiles to an ldr then str thumb instruction pair. The problem is that the ldr instruction starts reading from header two bytes before, and reverses the order of bytes in each pair of bytes read. Width is an int in both cases, and is the first variable in the structure.

Eg
Say memory looks like this:
Code:
08000000    55 66 00 01 00 00


and header points at 08000002, the instruction ldr r0, [r1, 0x0] , where r1 is correctly 08000002 is loading the value 0x66550100 into r0, rather than the desired value of 0x00000100. This is annoying. I havent edited the assembly code generated by g++ (version 2.9), and Im compiling with -O2. Could anyone offer some advice?

#30372 - tepples - Tue Nov 30, 2004 7:57 pm

How have you declared header in the calling program? On ARM7TDMI platforms, data structures including at least one 'int', 'long int', or pointer member should be aligned to a 4-byte boundary.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30455 - Mucca - Wed Dec 01, 2004 11:06 am

Ya the header structure is just a simple structure of three ints, the pointer points at the right place, and watching the variables of header also shows the correct values. The structure is declared in one of my header files, included wherever necessary. Just this ldr instruction is behaving strangely.

Another strange bug I have is that when I use more than a certain number of variables (more than about five or six) in a method, the compiler assigns a few of them the address 0x00000000, which is naturally not accessible so I cant even assign values to these variables. Writing to these variables seems to place the correct value in r0, but then r0 is not used when reading these variables, rather some junk value at location 0x00000000. Other variables are given registers.

edit:
Actually this business of two bytes previous to source address being copied is happening aswell on a dma copy elsewhere in my program. Its just weird, I supply, say, address 0x08000012 as the source address for the dma, and it actually starts at 0x08000010. Have never had problems with dma before and there's working dma copies in other places in the same program. Im puzzled. Is my link script doing something weird? Is my debugger confused in its dump display? Is God out to get me?

Oh, one more thing, the order of bytes is not affected with the dma glitch, just with ldr.

edit:
Hmmm, switching to 16 bit dma cured it, but the problem as you suggested seems to be alignment. I guess I better align the file Im reading from so that I always start on 4-byte boundaries.

final:
Well, 4-byte aligning does indeed solve it. Panic over, for another few hours at least. The other bug with variables being assigned address 0x00000000 when -O2 is used, and thus being unusable, is, I believe, just a bug in the debugger as it doesnt actually have any adverse affects on the program. Just looks weird.

#31575 - sasq - Sun Dec 12, 2004 1:29 pm

Not a bug, you can not rely on variable contents when debugging optimized code - it's like that for every debugger I've used.