Hi Kevin, glad to see you're still around :)
Kevin O'Connor wrote: > > I recently ported the haret application > (http://www.handhelds.org/moin/moin.cgi/HaRET) to mingwce32. In the > process, I used the c++ compiler, mainly because there were a few > places in the existing msvc code that would catch bad pointer accesses > and handle them gracefully. > > In the old code you'd see something like: > > __try > { > while (wcount--) > *vaddr++ = value; > } > __except (EXCEPTION_EXECUTE_HANDLER) > { > Complain (C_ERROR ("EXCEPTION while writing %08x to address %08x"), > value, vaddr); > } > > Which I converted to: > > try > { > while (wcount--) > *vaddr++ = value; > } > catch (...) > { > Output(C_ERROR "EXCEPTION while writing %08x to address %p", > value, vaddr); > } > > However, it doesn't work. (A bad memory access causes the program to > terminate.) What can be done to get this working? > Unfortunately, gcc doesn't support SEH. On x86 windows, people work around that with a few macros that result in a sintax quite similar. That is possible, because on x86, SEH is implemented as an linked list of exception handlers built on the stack. It works somewhat like setjmp/lonjmp (sjlj) schemes used to implement exceptions in C. On MSFT compilers, c++ exceptions are implemented on top of SEH, so a 'catch (...)' will also catch SEH exceptions. In gcc, we have sjlj exceptions (we use this variant), or DWARF2 exceptions, which don't know a thing about SEH, hence, the behaviour you see. Now, on ARM, SEH is table based, like DWARF2 exceptions are too. This means, the compiler must put unwind information in tables that the OS will read. Only the compiler and linker have enough information to build those tables. There is a very rudimentary SEH handler implemented in src/newlib/libc/wince/crt0.S, and src/newlib/libc/wince/startup.c, that install a catch all top level handler. You could install a top level handler like crt0.S does in your app, having but more handlers is something I don't think is practical to do manually. Perhaps you can rewrite those sections with IsBad{Write|Read|Code}Ptr [1], or VirtualQuery ? IsBadWritePtr, and friends internally do what you've done, so calling it on every byte may be slow, I don't know. If it is, you may get around by doing a binary search for a valid range with IsBadWritePtr, and then write away with memset/memcpy. Hope it helps, Cheers, Pedro Alves ------------------------------------------------------------------------- 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