Hi All, Op vr 20-04-2007, om 21:27 schreef Danny Backx: > I've done some more experiments. > > 1. I didn't get an exception from division by 0. > Inspection of the assembly code reveals that there's indeed no > division instruction being generated (probably this means ARM doesn't > do integer division?). The function called is divdf3, which comes from > dp-bit.c in gcc. That code explicitly checks for a 0 divider, it > doesn't appear to cause strangeness like an exception. >
The ARM has no integer division instruction. Only add / sub / mul instructions next to binary operations , shifts , branches and memory access instructions. It was designed as a simple hardwired RISC processor. > 2. Pedro asked why I used a dialog, wouldn't a printf statement be > better, he mentioned console applications. > I've tried to build a "console" version of my follow-a-null-pointer > application using the old voxware compiler. I used that toolchain > because I don't think ours can handle a console application that > can be launched from the rlogin session. hmm.. that would be an issue by itself. I have run different tests in a console on various things with cegcc but always used telnet for that. don know about rlogin on the pocket pc. > > The console application died as expected, showing messages that appear > to come from the _eh_handler_ : > > # np.exe > Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:11054 R0:0 > R1:29150 R2:2 R3:0 R4:2009fb64 R5:2009fc7c R12:1 FP:2009fb4c > Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:16194 > R0:ffffffff R1:0 R2:24be49ba R3:0 R4:c0000005 R5:0 R12:1 FP:2009fb4c > Exception: Code:80000002 Flags:0 Addr:16198 SP:2009fb44 LR:16194 > R0:ffffffff R1:0 R2:24be49ba R3:86 R4:c0000005 R5:ffffffff R12:1 > FP:2009fb4c > # why 3 exceptions? should not one be enough and stop the program ( or am I missing the correct mindset here to understand what is going on?) > > Interestingly, the divide-by-zero application (which pops up a dialog > after the division by 0) shows a dialog on my PDA's screen, even > though it was launched as a console application (from the rlogin > session). > could be from the floatingpoint emulator (if that exists on wince) > Note that the exceptions above mean : > #define STATUS_ACCESS_VIOLATION ((DWORD)0xC0000005L) > #define STATUS_DATATYPE_MISALIGNMENT ((DWORD)0x80000002L) > > 3. An application run without my modified _eh_handler_ prints messages > like these in /temp/wcetrace*.log. > > 4. I have an application that mysteriously dies when you ask it too > much. I was hoping to get some info from this handler, but I have yet > to find any error message. > Danny, the above statement is wonderfull.. You should never ask too much of an application ;-) Most people react in the same way if you ask too much of them :-) Just out of curiosity, what kind of app are you talking about and could you be more specific to the situation when it crashes? Stack overflow or something like that? (the memory model of wince is pretty restrictive i.m.h.o.) > When I run it under gdb, all that happens is : > Program received signal SIGSEGV, Segmentation fault. > 0x01758f58 in ?? () > (gdb) where > #0 0x01758f58 in ?? () > (gdb) > sounds like a trashed stack. This can happen when you define arrays within a function (created on the stack) and write outside the array bounds. > Danny I hope you get your cegcc stuff back in order. The stack trashing is very hard to avoid in gcc, programmers should just be more carefull when writing to certain memory locations. it looks like you are stumbling over some badly written pieces of code. Jan Rinze. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
