I was trying to make a simple static heap module, and when trying to verify proper operation of the heap functions via the debugger I got quite confused.
Whether I build and run the below code for an AT91SAM7S32 in the simulator or on my target hardware, local variables in the watch window change in ways that I just can't believe could be valid.
For example, when stepping through the heap_alloc function (for the first call to it from main), the blocksize variable changes every time I press F10 once I get into the part where I'm actually allocating the block. The comments show how the value of blocksize changes when I don't think it should be changing at all.
Can anyone shed any light on this...?
It doesn't matter whether I declare the heap variables at the top of the file as static or not, the wierd behavior is the same.
#define NULL (0) #define HEAP_SIZE (1000) static char the_heap[HEAP_SIZE]; static char* ptr_the_heap = the_heap; static int heap_left = HEAP_SIZE; int heap_size(void) { return(heap_left); } void* heap_alloc(int blocksize) { int remainder; int padding; void* ptr_block; // allocate blocks on 32-bit boundaries remainder = blocksize % 4; padding = 4 - remainder; blocksize += padding; if (blocksize <= heap_left) { ptr_block = (void*)ptr_the_heap; // blocksize changes to 0x3E8 (1000) here ptr_the_heap += blocksize; // blocksize changes to 0x200000 here heap_left -= blocksize; // blocksize changes to 0x20000C here return(ptr_block); // blocksize changes to 0x3E8 here } else { return(NULL); // not enough space on the_heap for blocksize } } int main(void) { volatile void *p1; volatile void *p2; volatile void *p3; volatile void *p4; p1 = heap_alloc(1); p2 = heap_alloc(2); p3 = heap_alloc(3); p4 = heap_alloc(4); while(p1); while(p2); while(p3); while(p4); return(0); }
Frustrated, Dave.
P.S. I previewed this post, but the preview of it got really screwy in the code listing part as soon as I started using the wheel on my mouse to go up and down through the post. I hope it doesn't look that way once I actually post it!
Hmmm... sounds like one more level of optimization might be needed to fix this problem. Perhaps that level should be called -1, since 0 is already taken. Seems to me that currently there is no way to turn all compiler optimizations off, which in my opinion markedly reduces the usefulness of the debugger.
I've submitted this situation to KEIL for customer assistance, and a dialog has begun.
Thanks Peter.
Dave.
Dave,
This is not a problem with the optimization level. It is a problem in the compiler where the debug information regarding the lifetime chains and locations is incomplete. This problem has already been addressed, the next compiler release will fix this. The current internal compiler release (under development) already fixes this issue. I need to find out when this new release will be available.
Regards, Peter
Many thanks Peter.
I'll be anxiously awaiting the next compiler release. Hopefully it'll be before my current support period expires.
When my wife recently me asked me how my day went, I told her about this and she asked "Why don't you just write your own tools?" I got a good chuckle out of that!
I've always been very pleased with the quality of KEIL products and their support. I'm glad to hear that this problem should disappear soon.
Thanks for your support, Dave.