>>>>> jkanze  <jkanze@otelo.ibmmail.com> writes:

> In article <u9wwav9f47.fsf@yorick.cygnus.com>,
>   Jason Merrill <jason@cygnus.com> wrote:
>>
>> >>>>> Paul D DeRocco <pderocco@ix.netcom.com> writes:
>>
>> > Well, perhaps that's technically true, but I'd be surprised if any major
>> > compiler that does both C and C++ does the former in a manner that
>> > breaks the exception handling of the latter.
>>
>> One of the G++ EH implementations uses tables of information to unwind the
>> stack.  This is not emitted by default for C code, so exceptions can't pass
>> through.  This was argued not to be a significant problem, since C code is
>> not likely to be exception-safe.

> Are the tables necessary for stack-walkback per se, or just for determining
> what cleanup code to call.

The former.

> I have code which does a stack walkback on an i80x86 (for VC++) and on a
> Sun Sparc (for Sun CC or g++); it doesn't count on any extra tables, and
> will walkback through a C function as well.  I would have thought that
> the only difference between my code and the exception handler is that at
> each stage of the walkback, the exception handler would try and look up
> the return address in the generated tables.  If it didn't find it,
> however, it should still be able to continue the walkback.

It is certainly possible to write a generic unwinder for non-flat Sparc
code; the register window is always in the same place.  There is no such
easy way to unwind frames on the x86, however; you don't know which
registers are saved where, so you can't restore them properly.  This is the
difference between an exception handler and your stack walker, I think; an
exception handler has to restore the contents of registers -- or avoid
holding things in callee-saved registers across calls that can throw, which
would severely impact optimization.

Jason
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jason Merrill wrote:
>
> > Are the tables necessary for stack-walkback per se, or just for
> > determining what cleanup code to call.
>
> The former.

I think the tables referred to by the previous poster included tables
showing what cleanup code had to be called over what ranges of
instruction addresses. But I also remember reading that G++ has two EH
implementations, one that works this way and one that doesn't.

> It is certainly possible to write a generic unwinder for non-flat
> Sparc code; the register window is always in the same place.  There is
> no such easy way to unwind frames on the x86, however; you don't know
> which registers are saved where, so you can't restore them properly.
> This is the difference between an exception handler and your stack
> walker, I think; an exception handler has to restore the contents of
> registers -- or avoid holding things in callee-saved registers across
> calls that can throw, which would severely impact optimization.

The other choice is to make any function that catches exceptions
(including those that temporarily catch them to call destructors) save
whatever registers it needs on its own behalf. That way, the stack
walking needs only to be able to follow the chain of stack frames, and
find the actual exception handling code. The exception handling code
then restores the registers it needs from its own save area.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> Now what happens when the signal is raised while C code is executed?
> The C compiler has no idea of exceptions, it doesn't create the
> necessary code for allowing exceptions to propagate through, it also
> won't know that it might have to protect it's frame building code
> against signals.

Well, perhaps that's technically true, but I'd be surprised if any major
compiler that does both C and C++ does the former in a manner that
breaks the exception handling of the latter. Of course, that confidence
must be tempered if the intervening C code is part of the OS, compiled
with a different compiler. However, this sort of thing seems to work
fine under Windows with synchronous callbacks.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> Paul D DeRocco <pderocco@ix.netcom.com> writes:

> Well, perhaps that's technically true, but I'd be surprised if any major
> compiler that does both C and C++ does the former in a manner that
> breaks the exception handling of the latter.

One of the G++ EH implementations uses tables of information to unwind the
stack.  This is not emitted by default for C code, so exceptions can't pass
through.  This was argued not to be a significant problem, since C code is
not likely to be exception-safe.

The other implementation uses setjmp/longjmp, which can of course throw
through anything.

Jason
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote:
>
> Christopher Eltschka wrote:
> >
> > Now what happens when the signal is raised while C code is executed?
> > The C compiler has no idea of exceptions, it doesn't create the
> > necessary code for allowing exceptions to propagate through,

> Well, perhaps that's technically true, but I'd be surprised if any major
> compiler that does both C and C++ does the former in a manner that
> breaks the exception handling of the latter.

An old version of CodeWarrior didn't allow exception through
C code. CodeWarrior is a major compiler. New releases don't
have this limitation, but the problem isn't unrealistic for
major compilers.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <u9wwav9f47.fsf@yorick.cygnus.com>,
  Jason Merrill <jason@cygnus.com> wrote:
>
> >>>>> Paul D DeRocco <pderocco@ix.netcom.com> writes:
>
> > Well, perhaps that's technically true, but I'd be surprised if any major
> > compiler that does both C and C++ does the former in a manner that
> > breaks the exception handling of the latter.
>
> One of the G++ EH implementations uses tables of information to unwind the
> stack.  This is not emitted by default for C code, so exceptions can't pass
> through.  This was argued not to be a significant problem, since C code is
> not likely to be exception-safe.

Are the tables necessary for stack-walkback per se, or just for determining
what cleanup code to call.  I have code which does a stack walkback on
an i80x86 (for VC++) and on a Sun Sparc (for Sun CC or g++); it doesn't
count on any extra tables, and will walkback through a C function as well.
I would have thought that the only difference between my code and the
exception handler is that at each stage of the walkback, the exception
handler would try and look up the return address in the generated tables.
If it didn't find it, however, it should still be able to continue the
walkback.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Petter Urkedal wrote:

[... about throwing exceptions from signal handlers ...]

> Now, there are two problems.  Some code is not written with
> the expectation that an exception may occur during execution.
> Secondly, it seems that throw() specifications has to be
> introduced in every function.  The following would solve both

Those are not the only problems. Look for examplew on the following:

extern "C" void f(); // This is *really* a C function

int main()
{
  setup_throwing_signal_handler();
  try
  {
    some_function_calling_f_sometimes();
  }
  catch(...)
  {
    cout << "exception thrown" << endl;
  }
}

Now what happens when the signal is raised while C code is executed?
The C compiler has no idea of exceptions, it doesn't create the
necessary code for allowing exceptions to propagate through, it also
won't know that it might have to protect it's frame building code
against signals.
When C++ functions are called directly from C functions, you know
that and will be careful to let no exception get through to the
C code. But signals can be raised during execution of C code,
Pascal code, FORTRAN code, or even hand written assembler, which
all may be called directly or indirectly from C++ functions.
You'd need a complete system to be aware of C++ exceptions if
they are to be thrown from signal handlers. What if the signal is
raised during a system call?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]