Re: [RFC / musing] Scoped exception handling in Linux userspace?

[Joseph S. Myers]

On Thu, 18 Jul 2013, Andy Lutomirski wrote:

> 2. It's localized.  So you can mmap something, read from it *and
> handle SIGBUS*, and unmap.

There is of course no guarantee that possibly faulting memory accesses are 
preserved (GCC should never introduce such an access where it wouldn't 
occur in the abstract machine, but may well *remove* accesses that aren't 
required).  Hopefully you don't want to rely on a guarantee that faults 
will happen....

> It's worth noting that SIGBUS isn't the only interesting signal here.
> SIGFPE could work, too.  I'm not sure whether SIGPIPE would make

The SIGFPE case could potentially be relevant for C bindings to IEEE 
754-2008 (clause 8) alternate exception handling, where the expectation is 
that various forms of exception handling attribute can be associated with 
a block.  Though what such bindings will end up looking like, and to what 
extent the various cases involved will correspond to things that could be 
implemented using SIGFPE, remains to be seen - checking floating-point 
exception flags after each operation could turn out to be a better 
implementation approach in some cases.  The C floating-point group hasn't 
got as far as designing such bindings yet (currently working on parts 1-3 
of draft TS 18661, and optional attributes are to go in part 5).

(Note: although I'm interested in these floating-point issues and am 
reviewing all the parts of the draft C bindings as they become available, 
I don't have current plans for implementing them - or the remaining bits 
of C99/C11 Annex F and Annex G not yet implemented in GCC.  There's 
certainly a lot of work to be done there in both GCC and glibc, with the 
exception handling attributes from part 5, and rounding mode attributes 
from part 1, probably among the larger pieces.)

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/