GP32 Debugging With No Optimisation

[foft]

I am getting a crash when some of my code is not optimised. At -O1 it works, but at -O0 it gives me a "Prefetch abort". It fails on an fprintf and I'm trying to work out why! It never reaches the _write in my syscall.c... Note that this is with Gcc 3.4.

Anyway I'm trying to work out which optimisation flag causes it to start working. I thought it might give me a clue what is going on.
The flags I use to build an optimised build are: ->works
CFLAGS = -Wall -O1 -march=armv4t -marm -mthumb-interwork -msoft-float -ffast-math -fshort-enums -nostdlib -fno-common -fno-builtin -fno-exceptions -mstructure-size-boundary=8 -fomit-frame-pointer $(INCLUDE)

For a non-optimised build: -> crashes
CFLAGS = -Wall -O0 -march=armv4t -marm -mthumb-interwork -msoft-float -ffast-math -fshort-enums -nostdlib -fno-common -fno-builtin -fno-exceptions -mstructure-size-boundary=8 -fomit-frame-pointer $(INCLUDE)

Then I tried adding the flags one at a time to do an equivalent of -O1. Even with all the flags it crashes! I believe it should be identical to -O1 (which works)? Did I miss anything?
CFLAGS = -Wall \
-fdefer-pop \
-fmerge-constants \
-fthread-jumps \
-floop-optimize \
-fif-conversion \
-fif-conversion2 \
-fdelayed-branch \
-fguess-branch-probability \
-fcprop-registers \
-march=armv4t -marm -mthumb-interwork -msoft-float -ffast-math -fshort-enums -nostdlib -fno-common -fno-builtin -fno-exceptions -mstructure-size-boundary=8 -fomit-frame-pointer $(INCLUDE)

Does anyone have any ideas? Am I passing gcc obviously wrong options here? I'll post my syscall.c and gpmain.c if it helps.

Thanks,

Mark

 

[foft]

Gah its memory related! Rebuilding other (unused files - different ones) causes it to fail:-(

Guess it must be some memory trashing in my syscalls.c or newlib. Probably mine!

Mark

 

[mithris]

Are you using both newlib malloc and gp sdk malloc?
Because that will cause problems..

---
mithris

 

[foft]

I think you're right... Though I did actually consider this.

I'd implemented my own _sbrk in terms of the gp sdk malloc:

caddr_t _sbrk(int incr){
FUNCTION
static int heapstart = 0;
static int size = 0;
int addr = size;
if (heapstart == 0)
heapstart = (int) gm_malloc(1024*512*2/*13*/);

DEBUG2("HEAPSTART:%x:%x", heapstart, addr);

size+=incr;
return (caddr_t)(heapstart + addr);
}

i.e. just grabbed a massive chunk from the sdk then passed that to newlib's malloc. I was allocating 7.5MB. This succeeded even on the debug build, though it causes the sdk function to fail cause they don't have enough memory! Doh! If only the SDK functions failed with SM_NO_MEMORY I'd have known what was wrong...

Thanks,

Mark