Peter Naulls wrote:
This is something I mentioned some months ago. None of the recent fixes help. Register dump at 000b6fb4: a1: 0 a2: c8 a3: 0 a4: 101 v1: 649c5ae8 v2: 649c5af0 v3: 649c5b34 v4: 28268 v5: 5cc40770 v6: 647cb808 sl: b11f0 fp: b35f4 ip: c8 sp: b35c8 lr: 5cbaa244 pc: 5cc40784 cpsr: 60000010 5cc40770 : ..-å : e52d0004 : STR R0,[R13,#-4]! 5cc40774 : .0 ã : e3a03001 : MOV R3,#1 5cc40778 : .Àá : e180c001 : ORR R12,R0,R1 5cc4077c : .4á : e1833403 : ORR R3,R3,R3,LSL #8 5cc40780 : ...ã : e31c0003 : TST R12,#3 5cc40784 : .À. : 0491c004 : LDREQ R12,[R1],#4 5cc40788 : .8á : e1833803 : ORR R3,R3,R3,LSL #16 5cc4078c : $... : 1a000024 : BNE &5CC40824 5cc40790 : . \à : e05c2003 : SUBS R2,R12,R3( b35f4) pc: 5c91a8e8 lr: 5c91b1dc sp: b35f8 nsLocalFile::FillStatCache()() ( b3610) pc: 5c91b174 lr: 5c9577d8 sp: b3614 nsLocalFile::GetFileSize(long long*)()
I spent a bunch of time on this, with -O0 builds, and lots of debug. The debug just moves the crash around, and can make it more repeatable, but doesn't actually let me narrow it down, although all of the crashes seem related to file handling. Of course, threading is always implicated, but given that this works ok in the static build, it looks a lot like a shared library handling problem. Also, my GDB no longer seems to want to work: This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"... I'm sorry, Dave, I can't do that. Symbol format `elf32-littlearm' unknown. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
