Kevin O'Connor wrote:
> On Tue, Jul 03, 2007 at 09:55:15PM +0100, Pedro Alves wrote:
>> Perhaps. Did you look closely? I've registered the .pdata stuff and
>> the data just before the function directly in the source file that
>> uses it. That means we can probably hide it in
>> more-or-less-easy-to-use macros in any function we want.
>
> I think future versions of gcc wont guarantee function placement
> relative to top-level asm statements.
>
Ah, you're paying attention. :) It will certainly fail today if
we use -ffunction-sections. If this ever turns into a real problem,
and we don't have real __try/__except support in the compiler, we
can craft an __attribute__((seh ("handler")) into gcc. I think that
is much easier.
>> It shouldn't. It should not be on by default. C++ exceptions are
>> one thing. SEH is another. Unless they are properly integrated at
>> the compiler level, they should only be mapped by the user. Let's
>> make it easy for the user to choose to use it instead.
>
> Heh, I never thought of it that way. I was working under the
> assumption that mingw32ce was trying to be fully compatible with the
> native CE compiler. However, now that you mention it, raising a C++
> exception due to an access violation seems like a pretty silly thing
> to do. (It helps in haret, because the only thing I use exceptions
> for are access violations, but in a general application...) I can
> understand if you don't want this behavior.
>
>> Think of it as func() being the __try {} block, and handler() being
>> the __except block. The user can use this to wrap seh into gcc's C++
>> exceptions. I certainly wouldn't want this in most of my c++ code.
>> I hate when try {} catch (...) { } catches access violations.
>> We can provide examples, and perhaps a lib for that to serve as example.
>>
>> Kevin's case is special, since he is writing a tool that
>> bypasses WinCE and accesses the physical memory and ARM registers
>> directly. How many here are doing that?
>
> Yes, it is special. I was reluctant to handle this locally in haret
> because I viewed it as a general problem. However, I'm starting to
> think that raising a c++ exception isn't a particularly good solution
> (despite what the msdn docs say).
>
> I guess what I really want is to call setjmp before the offending code
> and have a handler that will longjmp back to it if an access violation
> comes up. Doing this in a thread-safe manor is going to be a pain
> though.
>
> I'll try to take some of the sample code and integrate it into haret.
>
Great, please do post here your findings. I'd be curious if you take the
simplest route of not tweaking the current thread's context and just longjmp
from the seh handler, and if it brings any real problems (I don't think it's
safe, but it would be great to be proved wrong).
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
