[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros
From: |
Thomas Schwinge |
Subject: |
Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros |
Date: |
Mon, 6 Jun 2016 13:29:10 +0200 |
User-agent: |
Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (i586-pc-linux-gnu) |
Hi!
On Mon, 06 Jun 2016 09:06:35 +0200, ludo@gnu.org (Ludovic
=?utf-8?Q?Court=C3=A8s?=) wrote:
> Samuel Thibault <samuel.thibault@gnu.org> skribis:
> > Ludovic Courtès, on Sun 05 Jun 2016 21:53:35 +0200, wrote:
> >> Justus Winter <justus@gnupg.org> skribis:
> >> > +#define Mach_port_check(NAME)
> >> > \
> >> > + void _Mach_port_check_##NAME(char *_unused[] __attribute__
> >> > ((unused))) \
> >> > + {
> >> > \
> >> > + if (MACH_PORT_VALID (NAME))
> >> > \
> >> > + __print_fail_backtrace (#NAME " leaked",
> >> > \
> >> > + __FILE__, __LINE__, "Port leak detector");
> >> > \
> >> > + }
> >> > \
> >> > + char _Mach_port_check_x_##NAME[0]
> >> > \
> >> > + __attribute__ ((unused, cleanup (_Mach_port_check_##NAME)))
That, basically, is encoding the Mach API's semantic information using C
language constructs (specifically here, GCC extensions, which is OK in
our context, of course). As noted already, this will require us to touch
a lot of the existing code, to have it use this "new" API, basically.
Conceptually, such an improved API seems totally reasonable to me, and I
have thought about such things before.
I don't remember the details right now, but we also toyed with the idea
of a "rich" Mach port class in context of the "Improve Java on Hurd"
Google Summer of Code 2011 project,
<https://www.gnu.org/software/hurd/user/jkoenig/java.html>. (Jérémie
Koenig CCed, just in case.) See "Java bindings for Mach" on that page,
and <https://github.com/jeremie-koenig/hurd-java>. For example, the Java
variant of Justus' Mach_port_check quoted at the beginning of this email,
<https://github.com/jeremie-koenig/hurd-java/blob/master/mach/MachPort.java>:
/* Check that the port was deallocated and has no references left at
* collection time. */
@Override
protected final void finalize() {
if(refCnt > 0) {
System.err.println(String.format(
"MachPort: port name %d was never released", name));
refCnt = 0;
}
if(name != Mach.Port.DEAD) {
System.err.println(String.format(
"MachPort: port %d was never deallocated", name));
deallocate();
}
}
> >> I think writing a GCC plug-in that would automatically add a cleanup
> >> handler to automatic variables of type ‘mach_port_t’ wouldn’t be
> >> unreasonable.
> >
> > I don't enough to be sure, but isn't that the typical work of
> > LocalitySanitizer, precisely?
>
> Could be! I’m not familiar with it.
There is no LocalitySanitizer in GCC/LLVM. ;-)
<https://www.google.com/search?q="LocalitySanitizer"> says 'search -
"LocalitySanitizer" - did not match any documents'.
A compiler plugin certainly is one option to implement this. I just
wonder how many "special cases" we'll run into, where such a plugin needs
additional information, which then will require something like compiler
pragmas or type/variable/function attributes, telling the compiler plugin
what's going on?
It seems better to me, to keep all that information close together: where
the Mach API is described, the Mach header files, if you will.
The next thought then occurred to me: why not use a programming language
that allows for defining additional types, powerful enough to model the
desired semantics? For example, if we'd compile the Hurd with a C++
compiler (which, hopefully, will just work -- mostly), could we then
create a mach_port_ta C++ class, wrapping the "primitive" Mach data type,
and teach that one the Mach API semantics? For example, that a port
right locally "goes away" after move/transfer operations, or that at the
end of any scope any local ports rights must have "gone away" to avoid
leaks.
Both in Justus' C variant, the compiler plugin variant, and the C++
variant, it seems reasonable to assume that the compiler will be able to
optimize away most of such checking code.
So, I don't know what peoples' feelings are about C++, but perhaps that's
worth considering, assuming that we can come up with a concise design of
a mach_port_t class, and others. I'm sure similar things/designs have
been done in other contexts, where there is a difference between
copy/duplicate/move/transfer operations, for example. (What does
"assignment" with the "=" operator mean, for example...)
Grüße
Thomas
signature.asc
Description: PGP signature
- RFC: Runtime checking of port handling, Justus Winter, 2016/06/04
- [PATCH hurd 1/2] xxx print fail, Justus Winter, 2016/06/04
- [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Justus Winter, 2016/06/04
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Ludovic Courtès, 2016/06/05
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Samuel Thibault, 2016/06/05
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Ludovic Courtès, 2016/06/06
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros,
Thomas Schwinge <=
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Samuel Thibault, 2016/06/06
- Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros, Ludovic Courtès, 2016/06/06
Re: [PATCH hurd 1/2] xxx print fail, Samuel Thibault, 2016/06/04
Re: RFC: Runtime checking of port handling, Samuel Thibault, 2016/06/04