Hi!
On Sun, Jul 08, 2007 at 08:20:49PM +0100, Pedro Alves wrote:
> Hi all,
>
> Here goes the v2 of the seh giga macros. Wear sunglasses.
>
> * __finally blocks don't eat the exception anymore.
>
> * The filter in __except (filter), is now really an
> expression, thanks to gcc's preprocessor
Nuno Lucas wrote:
>
> Doesn't the "You got a segfault" message comes from the current active
> system debugger on Windows?
> I thought this was what DrWatson (the default system debugger) did for
> Windows. But when you install the Microsoft IDE it usually installs a
> new system debugger, which a
On Mon, 2007-07-09 at 21:49 +0100, Pedro Alves wrote:
> >> _cegcc_main_data:
> >> .word 0 /* _cegcc_main_handler */
> >> .word 0 /* _cegcc_main_size */
> ^^^
> This is not supposed to be the size, but a pointer
> to data to the passed to the handler. The size g
Danny Backx wrote:
>
> I've had little time to spend on this recently, but I've approached
> things the other way. If I get far enough, then maybe both may meet.
>
Yes. What you're doing would be the very minimum we need to do
to have the compiler output the needed structures.
> I fiddled with
On Sun, 2007-07-08 at 20:20 +0100, Pedro Alves wrote:
> Here goes the v2 of the seh giga macros. Wear sunglasses.
Interesting stuff.
I've had little time to spend on this recently, but I've approached
things the other way. If I get far enough, then maybe both may meet.
I fiddled with gcc/config
Hi all,
Here goes the v2 of the seh giga macros. Wear sunglasses.
* __finally blocks don't eat the exception anymore.
* The filter in __except (filter), is now really an
expression, thanks to gcc's preprocessor varargs (__VA_ARGS__).
* Nested blocks work for the testcase included. I didn't
Hi Kevin,
A couple of comments before I digest this when I get home.
On 7/6/07, Kevin O'Connor wrote:
> > Kevin O'Connor wrote:
> >
>
> > struct eh_data {
> > jmp_buf env;
> > __seh_filter filter;
> > };
>
> This should probably include a "struct eh_data *old_handler", so that
> nested try bl
On Fri, Jul 06, 2007 at 03:03:41AM +0100, Pedro Alves wrote:
> Kevin O'Connor wrote:
> >Earlier on, I tried to use the same __try/__except syntax that msdn
> >documents. However, I gave up on it - it was too complicated and not
> >useful for me. In particular, implementing __finally would be
> >p
Pedro Alves wrote:
>
> EXCEPTION_DISPOSITION
> eh_handler(struct _EXCEPTION_RECORD *ExceptionRecord,
>void *EstablisherFrame UNUSED,
>struct _CONTEXT *ContextRecord,
>struct _DISPATCHER_CONTEXT *DispatcherContext UNUSED)
> {
> struct eh_data *d = TlsGetValu
On 7/4/07, Pedro Alves <[EMAIL PROTECTED]> wrote:
> Danny Backx wrote:
> > 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.
>
> I understand that. I also get bitten by this from tim
On Thu, Jul 05, 2007 at 02:54:33AM +0100, Pedro Alves wrote:
> #define TRY_EXCEPTION_HANDLER \
> struct eh_data __ehd; \
> int __ret = setjmp(__ehd.env); \
> if (!__ret) { \
> start_ehandling(&__e
Kevin O'Connor wrote:
> On Thu, Jul 05, 2007 at 01:46:30AM +0100, Pedro Alves wrote:
>> This is the part I was trying to get right with the macros:
>>
>>> __asm__(
>>> // Data to be placed at start of .text section
>>> "\t.section .init\n"
>>> "\t.word eh_handler\n"
>>> "\t.word 0\n
On Thu, Jul 05, 2007 at 01:46:30AM +0100, Pedro Alves wrote:
> This is the part I was trying to get right with the macros:
>
> > __asm__(
> > // Data to be placed at start of .text section
> > "\t.section .init\n"
> > "\t.word eh_handler\n"
> > "\t.word 0\n"
> > "start_eh_text:
This is the part I was trying to get right with the macros:
> __asm__(
> // Data to be placed at start of .text section
> "\t.section .init\n"
> "\t.word eh_handler\n"
> "\t.word 0\n"
> "start_eh_text:\n"
>
This is documented to having to be placed immediately before the func
On Wed, Jul 04, 2007 at 11:31:30PM +0100, Pedro Alves wrote:
> Kevin O'Connor wrote:
> > 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
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
Danny Backx wrote:
> 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
Kevin O'Connor wrote:
>> DWORD* sp = (DWORD*)ContextRecord->Sp;
>>*--sp = ContextRecord->Pc;
> [...]
>
> Sp is the stack of the main code, and the exception handler writes to
> that stack space. Are we guarenteed that if we longjmp back to the
> main code that it wont corrupt anything? (In
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
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 functi
On Mon, Jul 02, 2007 at 12:38:48AM +0100, Pedro Alves wrote:
> Kevin O'Connor escreveu:
> > Is it safe to enter an exception handler using the calling program's
> > stack? That is, if you set the pc to a handler and call
> > EXCEPTION_CONTINUE_EXECUTION that handler will alter the stack and
> > re
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 sho
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
Pedro Alves wrote:
Kevin O'Connor wrote:
On Sun, Jul 01, 2007 at 08:12:33PM +0100, Pedro Alves wrote:
Danny Backx wrote:
void Handle(struct _EXCEPTION_RECORD *ExceptionRecord,
void *EstablisherFrame,
struct _CONTEXT *ContextRecord,
struct _DISPAT
On Mon, 2007-07-02 at 00:38 +0100, Pedro Alves wrote:
> Kevin O'Connor escreveu:
> > On Sun, Jul 01, 2007 at 08:12:33PM +0100, Pedro Alves wrote:
> >> Danny Backx wrote:
> >>> void Handle(struct _EXCEPTION_RECORD *ExceptionRecord,
> >>> void *EstablisherFrame,
> >>> struct _CONT
Kevin O'Connor escreveu:
> On Sun, Jul 01, 2007 at 08:12:33PM +0100, Pedro Alves wrote:
>> Danny Backx wrote:
>>> void Handle(struct _EXCEPTION_RECORD *ExceptionRecord,
>>> void *EstablisherFrame,
>>> struct _CONTEXT *ContextRecord,
>>> struct _DISPATCHER_CONTEXT
On Sun, Jul 01, 2007 at 08:12:33PM +0100, Pedro Alves wrote:
> Danny Backx wrote:
> > void Handle(struct _EXCEPTION_RECORD *ExceptionRecord,
> > void *EstablisherFrame,
> > struct _CONTEXT *ContextRecord,
> > struct _DISPATCHER_CONTEXT *DispatcherContext)
> > {
>
Danny Backx wrote:
> On Sun, 2007-07-01 at 09:41 -0400, Kevin O'Connor wrote:
>> On Fri, Jun 22, 2007 at 09:37:21PM +0200, Danny Backx wrote:
>>> The null.C example however - when used with my exception handling code -
>>> shows a dialog from my new exception handler, but never makes its way to
>>>
On Sun, 2007-07-01 at 09:41 -0400, Kevin O'Connor wrote:
> On Fri, Jun 22, 2007 at 09:37:21PM +0200, Danny Backx wrote:
> > The null.C example however - when used with my exception handling code -
> > shows a dialog from my new exception handler, but never makes its way to
> > the C++ exception han
On Fri, Jun 22, 2007 at 09:37:21PM +0200, Danny Backx wrote:
> The null.C example however - when used with my exception handling code -
> shows a dialog from my new exception handler, but never makes its way to
> the C++ exception handler.
Have you figured out a way to raise a c++ exception from t
30 matches
Mail list logo
