Re: [RFA][PATCH] Isolate erroneous paths optimization

[Ian Lance Taylor <iant at google dot com>]

On Mon, Nov 11, 2013 at 10:55 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Simply trapping doesn't tell you anything about caused the trap.
>> There are at least two distinct possibilities: NULL pointer
>> dereference and integer division by zero.  There should be some way to
>> distinguish those two cases.  It's reasonably easy to do so in a
>> signal handler.  When should we do if the compiler generate a call to
>> __builtin_throw?
>
> You would use the fallback code in the signal handler, throwing the exception
> used when you don't know the precise cause of the erroneous execution.  Or
> else we could pass an argument to __builtin_throw, but we would need some low-
> level convention to pass it on to the handler.

For Go that would be a (probably minor) degradation.  Right now the
signal handler knows whether it is looking at a NULL pointer
dereference or a division by zero, because it gets a different signal.
On most modern systems you can be even more precise by looking at the
siginfo struct, and the Go runtime does do that.

But looking even lower-level, what we are talking about here is a
generic function that will be in libgcc, not a language-specific
function.  That function could throw a general exception, but it can't
invoke any language-specific approach.  And that general exception
would have to have some generic label.  But I guess that the
language-specific personality function could recognize that generic
label and take some appropriate action.

Ian