GCC and LLVM/clang provide several sanitizers, http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation, such as:

Porting these to the Hurd is not a trivial task, for they have intimate knowledge about the operating system kernel they're running on, and reimplement the needed parts of glibc by directly using system calls -- which is basically a no-go on GNU Hurd.

Samuel took some look at it and got some basic support for libubsan and libasan by making it call glibc still: https://people.debian.org/~sthibault/hurd-i386/libubsan-hurd.diff which allowed to fix some issues in the hurd code.

This needs to be updated to a newer gcc and submitted upstream.

IRC, OFTC, #gcc, 2012-12-11

<richi> hmm, is libtsan not multi-libbed?
<jakub> richi: it only works on x86_64 right now
<richi> ugh
<jakub> richi: so, it is multilibbed, but only built on multilibs and
  targets which are supported
<jakub> richi: as it often needs lots of RAM, it is probably not going to
  be supported on 32-bit targets at all
<jakub> richi: no reason not to support it on say ppc64 or sparc64 or s390x
  I guess, just needs work
<richi> jakub: where is asan supported?  everywhere?
<jakub> richi: but then, I haven't even read what exactly libtsan does,
  only looked at the atomics in there, and did the GCC side from what I
  knew should be instrumented
<jakub> richi: asan is right now supported on x86_64/i686, ppc/ppc64,
  perhaps partially x86 darwin (don't care) and in theory arm (nobody
  tested)
<jakub> richi: porting isn't that hard, but the library isn't as clean as
  it would be desirable portability wise
<jakub> richi: that said, I don't want to spend as much time as I've done
  so far on it, and in the time I'll allocate for it optimizing the code it
  generates is higher on the todo list than ports to other targets

2015-04-14

id:"20150414130851.GA6154@type.bordeaux.inria.fr".