This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Mon, Nov 11, 2013 at 10:55 AM, Eric Botcazou <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]