Re: EGCS vs MSVC - exception handling

Re: EGCS vs MSVC - exception handling

[Mike Stump]

> To: egcs@cygnus.com
> From: Arun Sharma <asharma@netscape.com>
> Date: 12 Jan 1998 23:39:56 -0800

> Why would that be necessary ? Inside the signal handler, I know
> precisely which instruction generated the trap by looking into the
> sigcontext.

Bingo, that's it.  Unfortunately, one needs to look at the current PC
and only when the top of the stack is hit (the original signal handler
frame), then switch over to the sigcontext.  gcc hasn't been taught
about this yet.

You can get it to work, by using -fsjlj-exceptions.

Re: EGCS vs MSVC - exception handling

[Arun Sharma]

The following message is a courtesy copy of an article
that has been posted to comp.os.linux.development.apps as well.

Paul Flinders <PaulFl@finobj.com> writes:
> 
> void handle_segv()
> {
> 	Segv exception ;
> 	
> 	throw ( exception );
> }
> 
> Should just about do it with the exception of unblocking signals (which
> you need to do as never exit the signal handler normally).
> 

A throw from the signal handler results in a core dump. One needs to
do more work to get this to work. Someone on the egcs list might have
already done this.

	-Arun

PS: The thread was about being able to catch null pointer exceptions
in egcs.

Re: EGCS vs MSVC - exception handling

[Jeffrey A Law]

  In message < sn04t39h9eb.fsf@zugzwang.mcom.com >you write:
  > A throw from the signal handler results in a core dump. One needs to
  > do more work to get this to work. Someone on the egcs list might have
  > already done this.
That requires quite a bit more work.  You might start with adding
-fasynchronous-exceptions to the command line (or something close to that)
which instructs flow to create an edge from every insn to its EH handler
(since just about any insn could trap into a signal handler).


jeff

Re: EGCS vs MSVC - exception handling

[Arun Sharma]

Jeffrey A Law <law@cygnus.com> writes:

> That requires quite a bit more work.  You might start with adding
> -fasynchronous-exceptions to the command line (or something close to that)
> which instructs flow to create an edge from every insn to its EH handler
> (since just about any insn could trap into a signal handler).

Why would that be necessary ? Inside the signal handler, I know
precisely which instruction generated the trap by looking into the
sigcontext. All I need to do is to be able to unwind the stack and
look for the right exception handler to call.

The normal stack unwinding mechanism starts from the current pc and
sp, but in this case, it needs to go through the pc and sp in
sigcontext.

	-Arun

Re: EGCS vs MSVC - exception handling

[Andreas Schwab]

Arun Sharma <asharma@netscape.com> writes:

|> Jeffrey A Law <law@cygnus.com> writes:
|>> That requires quite a bit more work.  You might start with adding
|>> -fasynchronous-exceptions to the command line (or something close to that)
|>> which instructs flow to create an edge from every insn to its EH handler
|>> (since just about any insn could trap into a signal handler).

|> Why would that be necessary ? Inside the signal handler, I know
|> precisely which instruction generated the trap by looking into the
|> sigcontext. All I need to do is to be able to unwind the stack and
|> look for the right exception handler to call.

The sigcontext is as unportable as you can get.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: EGCS vs MSVC - exception handling

[Jeffrey A Law]

  In message < sn090sk7rg3.fsf@zugzwang.mcom.com >you write:
  > > That requires quite a bit more work.  You might start with adding
  > > -fasynchronous-exceptions to the command line (or something close to that
  > )
  > > which instructs flow to create an edge from every insn to its EH handler
  > > (since just about any insn could trap into a signal handler).
  > 
  > Why would that be necessary ? Inside the signal handler, I know
  > precisely which instruction generated the trap by looking into the
  > sigcontext. All I need to do is to be able to unwind the stack and
  > look for the right exception handler to call.
You have to be able to map from any instruction that might throw to its
associated handler.  If you're throwing from a signal handler, then
basically every insn might throw, so each and every insn must have an
edge to its associated handler.

It has nothing to do with unwinding the stack.  It's what you do *after*
the stack is unwound that requires these extra edges.

jeff

Re: EGCS vs MSVC - exception handling

[Richard Henderson]

On Mon, Jan 12, 1998 at 11:39:56PM -0800, Arun Sharma wrote:
> Jeffrey A Law <law@cygnus.com> writes:
> 
> > That requires quite a bit more work.  You might start with adding
> > -fasynchronous-exceptions to the command line (or something close to that)
> > which instructs flow to create an edge from every insn to its EH handler
> > (since just about any insn could trap into a signal handler).
> 
> Why would that be necessary ? Inside the signal handler, I know
> precisely which instruction generated the trap by looking into the
> sigcontext. All I need to do is to be able to unwind the stack and
> look for the right exception handler to call.

Except that once you've found the handler and jumped to it, you'll
want to use some variables.  This means the register allocator must
know how control flows between the exception region and the handler.


r~