Hi, Just want to say thanks for helping me and want to post solution which worked for me; so that anyone facing similar issue can try this. I used -O2 rather than -Os in my compiler options and the problem vanished from all components. So somehow using option -Os optimizes the size _but_ seems to be messing with function arguments (I looked at assembler code generated by armv5l-linux-gcc and found big differences in argument passing between -Os and -O2). So my current compiler options are: armv5l-linux-g++ -Wall -Wno-write-strings -mcpu=arm9 -O2 -DARM9_LINUX_GCC -D_GNU_SOURCE -DUNIX -pipe -fPIC -c -o xxxxxxx.o xxxxxxx.cc Regards, -- Fawad Lateef P.S. I did top-posting rather than bottom-posting because I am not replying to some comments. On Wed, May 25, 2011 at 12:07 PM, Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> wrote: > > Fawad Lateef wrote: > > > > Personally, I'd be more inclined to suspect register corruption. Are > > > you calling a library function which use a different ABI? E.g. if your > > > code is compiled for an ABI where certain registers are preserved but > > > calling a function using an ABI which doesn't preserver those > > > registers, then you'll have problems. > > > > humm, Can you give some suggestion about how to verify this ? Using > > readelf or objdump on different libraries and executables can give > > some clue ? As we are using some pre-compiled libraries provided by > > some stack we are using. > > The files themselves may not contain sufficient information. E.g. if > someone builds a library using e.g. -mregparm=3, that isn't going to > show up in the objdump (etc) output. First, check the documentation > for the libraries; if that doesn't help, try disassembling them. > > -- > Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
