Kevin O'Connor wrote:
> Hi Pedro,
>
> I'm going to reply to both your emails here.
>
> On Sat, Jun 02, 2007 at 08:20:12PM +0100, Pedro Alves wrote:
>> Hi Kevin,
>>
>> glad to see you're still around :)
>
> Heh, my silence was just because everything has been working really
> well. :-)
>
> On Sun, Jun 03, 2007 at 07:01:35PM +0100, Pedro Alves wrote:
>> Danny Backx wrote:
>>> I'm not sure we're talking about the same things here.
>>>
>> Yes, we are. Kevin wants __try/__except, which is syntax sugar on
>> top of SEH. Start here for info on SEH on ARM WinCE:
>
> To be clear, I'm not too concerned about using SEH or some other
> mechanism. My goal is just to be able to prevent some access errors
> from terminating the program.
>
> [...]
>> The exception c++ model that both mingw32ce and cegcc use is the sjlj model.
>> It is similar with the SEH model on x86. It certainly works.
>>
>> SEH is an OS thing, so it always works, but it happens that registering
>> handlers manually is much harder on ARM than it is on x86/9x/NT.
>
> So, is it possible to have mingw32ce install a global SEH handler that
> just translates the exception into an sjlj one? That is, can we
> modify the standard crt0.S file so that it causes wince exceptions to
> raise C++ exceptions that g++ can then handle?
>
Maybe, but it would be tricky. Hummm, I guess calling it top level
is wrong here. A normal top level handler, is the catch-all
that runs after all of the stack is unwound, so there is no way
to resume the app. But since we can install a (subverting what
the OS expects) handler that has a 'number of insns' very big,
the stack isn't unwound at all. On a SEH handler, you are allowed
to change the context of the excepted thread. Eg, you can create a
stack frame on the context of the thread that triggered the exception,
in which you point the $PC to a function of your own. You return
EXCEPTION_CONTINUE_EXECUTION from the SEH handler. Now, Windows
will resume the thread, and the control will pass to your $PC. If
you set the $PC to a function that throws a c++ exception, it may work.
There are probably other things that that needs to be setup
on the stack linking into the previous frame on the sjlj model, You'd
have to study it a bit.
The cegcc's crt0.S, start.c and __eh_handler.S files implement
something similar which may help as a starting point.
> [...]
>> SEH is used internally by the OS dlls. For example, the IsBadWritePtr
>> function
>> I was suggesting to Kevin, internally does something like:
> [...]
>> So Kevin's code could be rewritten as something like:
>>
>> while (wcount--)
>> {
>> if (IsBadWritePtr (vaddr, sizeof (*vaddr)))
>> {
>> Complain (C_ERROR ("EXCEPTION while writing %08x to"
>> "address %08x"),
>> value, vaddr);
>> }
>> else
>> {
>> *vaddr = value;
>> }
>> ++vaddr;
>> }
>
> In the original haret code, there were two uses for the __try/__except
> stuff: to catch invalid memory reads/writes, and to catch invalid
> instructions. The memory accesses are the most common thing that
> users bump into.
>
> However, I'm a bit concerned with using IsBad{Read,Write}Ptr. It's
> not clear to me from the docs that the wince code for this really
> tests whether or not the access will succeed - it may be trying to
> verify that the pointer is in a valid looking address range. One of
> the things Haret needs to be able to do is to access obscure areas of
> memory (directly accessing hardware registers, wince internals, and
> other apps). I really want to try the access and then handle the
> fault if one occurs. If I ask wince if the pointer is valid, it may
> come back and say "no - that pointer is not in your address space",
> but that may be just what the user wants to do!
>
You're right, the WinCE version of the docs isn't clear. I've seen
several discussions on IsBad*Ptr, and always understood it as using
a __try/__except block inside.
The 9x/NT version of the docs state that:
http://msdn2.microsoft.com/en-us/library/aa366716.aspx
"If the application is run under a debugger and the process does not have write
access to all bytes in the specified memory range, the function causes a first
chance STATUS_ACCESS_VIOLATION exception. The debugger can be configured to
break for this condition. After resuming process execution in the debugger, the
function continues as usual and returns a nonzero value This behavior is by
design and serves as a debugging aid."
That STATUS_ACCESS_VIOLATION is the SEH exception the __except block
would catch. It isn't clear if without a debugger the function behaves
the same way.
I don't know if the WinCE version behaves the same way or not.
Anyway, nothing like testing it, eh?
<need a hammer?>
You can also try creating a child process to take care of
the dangerous writing. If the app crashes, you know you had a bad pointer :)
You could feed the data to the child process through some kind of IPC.
Eh, pipes would be nice. :)
</need a hammer?>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
