[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1682637.1704846564@warthog.procyon.org.uk>
Date: Wed, 10 Jan 2024 00:29:24 +0000
From: David Howells <dhowells@...hat.com>
To: Andrew Pinski <pinskia@...il.com>
Cc: dhowells@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/45] C++: Convert the kernel to C++
Andrew Pinski <pinskia@...il.com> wrote:
> Note even in GCC, we disable exceptions and RTTI while building GCC.
> This is specifically due to not wanting to use them and use other
> methods to do that.
> Note GDB on the other hand used to use setjmp/longjmp for their
> exception handling in C and I think they moved over to using C++
> exceptions which simplified things there. But as far as I know the
> Linux kernel does not use a mechanism like that (I know of copy
> from/to user using HW exceptions/error/interrupt handling but that is
> a special case only).
If we were to allow exception handling, I wonder if we would actually need to
throw anything other than a signed long integer (e.g. an error code) and just
disable RTTI. Maybe something like:
long sys_rename(...)
{
struct rwsem_lock lock_a, lock_b;
struct inode *dir_a, *dir_b;
...
try {
if (dir_a > dir_b) {
lock_a.down_write_killable(dir_a);
lock_b.down_write_killable(dir_b);
} else {
lock_b.down_write_killable(dir_b);
lock_a.down_write_killable(dir_a);
}
} catch (-EINTR) {
throw -ERESTARTSYS;
}
...
}
then have a cut-down exception unwinder that only needs to deal with long
values.
However, I think rolling out exception handling in the kernel might be too big
a task, given the huge amount of code involved - however much we might like to
avoid all those return value checks.
David
Powered by blists - more mailing lists