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