Pedro Alves wrote:
> 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,
>
Forgot to add the [1]. Here it is:
[1] - They have their own problems, at least on x86 (stack guard
pages + multithreading - google is your friend), and their usage is
discouraged. But in this case I don't see any other way.
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
