[Top][All Lists]

[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)


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,

        /* Check that the port was deallocated and has no references left at
         * collection time. */
        protected final void finalize() {
            if(refCnt > 0) {
                            "MachPort: port name %d was never released", name));
                refCnt = 0;
            if(name != Mach.Port.DEAD) {
                            "MachPort: port %d was never deallocated", name));

> >> 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

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...)


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]