On Tue, 2007-07-03 at 21:55 +0100, Pedro Alves wrote:
> Danny Backx wrote:
> > On Tue, 2007-07-03 at 03:14 +0100, Pedro Alves wrote:
> >>> Let me see if I can come up with something in the following days.
> >> OK, here is my take.  See/try attached.
> >>
> >> - It shows that it is possible to have SEH/ARM with a few
> >>    macros (to hide the __asm__).
> >> - It shows that is is possible to wrap SEH in c++ exceptions.
> >> - It shows that is can be pretty much cleaned up. :)
> >> - It shows that there is no need to change the entry point.
> > 
> > As I wrote the other day, I have something similar in the works. My
> > version looks a lot like yours because basically you did now what I did
> > last week :-)
> > 
> 
> 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 did look closely. This was one of the reasons why I said you had
clearly done more work on assembler code.

> > I also have my version properly integrated in src/mingw so my local
> > version of arm-wince-mingw32ce-gcc picks this up automatically. That
> > wasn't hard.
> 
> If you get macros going on, then we can wrap the default WinMain
> with the equivalent of __try/__except.  I don't like the changing the
> entry point into asm copied directly from cegcc.  Among other problems,
> it only works in the main thread.  Any other thread will still blow
> up on an exception happening.

I'd like to have two discussions. We're already having them both, that's
very good. I'd like to discuss design goals, and implementation. Both
are important. You'll find I might change the topic from one to the
other at times.

Maybe I'm too vague, allow me to clarify.

Design goals would e.g. state that you want all functions to potentially
have an exception handler - like what SEH says - or that you want
non-main threads to have an exception handler.

The implementation discussion might be about whether you do this in
macros - your current suggestion - or in the compiler itself. The latter
idea is probably too hard anyway but I wanted to bring it up for the
sake of discussion.

Back to our topic. I think you said that :
D1. __try and its friends are a construction which we'd like to support.
    Basically this is part of SEH, isn't it?
D2. Have a wrapper for function definitions so you can install an
    exception handler on any function.
D3. Use that to implement a default exception handler for WinMain.
D4. A developer can choose to use that wrapper on the function that
    implements other threads.
I1. Don't change the entry point in crt*.o. (I'm not sure I understand
    why, maybe this is purely related to D3/D4.)
I2. Use macros to implement the wrapper around function definitions.

> > Haven't done that for C++ yet because Kevin's message prompted me to
> > reveal what I was playing with. I am in the process of figuring out
> > which C++ constructs this should use, and (depending on that) how the
> > hook from C++ into the mingw startup should work.
> > 
> 
> 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.

D5. You want to offer SEH as an option, the developer can choose not to
    use it.
D6. The developer may also want to use C++ exceptions, they should not
    be mandatory (as my example and the accompanying text suggested).

> Please stuff like this:
> http://blogs.msdn.com/david_leblanc/archive/2007/04/03/exception-handlers-are-baaad.aspx
> (Particularly funny that the first post comes from a CE team guy).
> 
> Another point of view, is that there isn't any standard class to
> throw in the presence of a SEH exception.  We shouldn't force any
> particular class we invent on the users.  We should provide the
> tools to have them build the class hierarchy they want.  There
> are examples of that all over the web (google: seh c++ exceptions).

Yes I already did that.

> #define SEH_FUNC_START(...) ...
> #define SEH_FUNC_END(...) ...
> #define SEH_FUNC_REGISTER(...) ...
> 
> handler()
> {
>       users handler here.
> }
> 
> 
> int func ();
> 
> SEH_FUNC_REGISTER (func, handler);
> 
> int func ()
> {
>       SEH_FUNC_START (func); < really prologue end.
> 
>       ...
> 
> 
>       SEH_FUNC_END (func);
> }

Hmm, I can't say I'm particularly fond of this. But obviously neither
are you.

> 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.

Why do you hate that ?

I hate it when applications on my PDA disappear without a trace.
"Something must have gone wrong" is all you've got. That's the reason I
started on all this.

> 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?
> 
> > Opinions on how to do this in C++ are welcome, my C++ is still rusty :-)
> > 
> 
> > Pedro appears to have spent more time in the assembler code than I did.
> > (Thanks, Pedro.) I'll merge this into my version in the coming days.
> > 
> 
> The __eh_continue.S was directly copied from cegcc... The __asm__ blocks
> took me a bit to get right, until I realized I was mapping bit fields into
> shifts completely mirrored.  They do more or less what the compiler would
> emit if it had basic support for SEH.  Looking at a few examples on the
> web, it seems to be safe to throw from a SEH handler, but still not
> convinced that is safe, especially for CE/ARM/Risc SEH.  That being said,
> the asm/'thread context handling' code I posted could certainly be
> simplified.

Yeah, we need to look into that too.

I'll add a couple more :
D7. We should have both a C and a C++ solution.
    The CegccSetExceptionHandler in my example could be that.
D8. We should offer some examples and tools.
I3. The classes WindowsException, AccessViolation, .. from my example
    could be one of these tools.

As you know, I'm writing all this for the sake of discussion, not
because I feel strongly about something.

        Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
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

Reply via email to