unwindonsignal variable question

unwindonsignal variable question

[Phil Muldoon]

Setting this to "on" fixes the most problematic aspects of gnats pr 
2495. (This is where an exception is raised in a C++ function executed 
by inferior function call, and no in-frame exception handler results in 
a sigabrt being delivered to the inferior).

As this is a very useful flag, and it only seems to apply in inferior 
function calls, I am curious why it appears to default as "off", 
requiring the user to perform:

set unwindonsignal on

(I'm not advocating changing it, just curious if there is a  particular 
reason for it to be this way). And also, if there would be known 
side-effects to having it to default as on.

Regards

Phil

Re: unwindonsignal variable question

[Daniel Jacobowitz]

On Tue, Sep 16, 2008 at 04:57:24PM +0100, Phil Muldoon wrote:
> Setting this to "on" fixes the most problematic aspects of gnats pr 2495. 
> (This is where an exception is raised in a C++ function executed by 
> inferior function call, and no in-frame exception handler results in a 
> sigabrt being delivered to the inferior).
>
> As this is a very useful flag, and it only seems to apply in inferior  
> function calls, I am curious why it appears to default as "off",  
> requiring the user to perform:
>
> set unwindonsignal on
>
> (I'm not advocating changing it, just curious if there is a  particular  
> reason for it to be this way). And also, if there would be known  
> side-effects to having it to default as on.

Well, it makes things harder if the abort is what you're trying to
debug.

It would be nice if there was a single command that would do this:
discard the dummy frame and clear the received signal...

-- 
Daniel Jacobowitz
CodeSourcery