[[!meta copyright="Copyright © 2012, 2013, 2015 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!meta title="Port the GCC and LLVM/clang Sanitizers (*san) to the Hurd"]]

[[!tag open_issue_gcc open_issue_llvm]]

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

  * Address Sanitizer, a memory error detector (ASan; `-fsanitize=address`)

    [Finding races and memory errors with GCC instrumentation
    (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29),
    GNU Tools Cauldron 2012.  <http://code.google.com/p/address-sanitizer/>.

  * Memory Sanitizer, an detector of uninitialized reads (MSan;
    `-fsanitize=memory`)

    <http://code.google.com/p/memory-sanitizer/>

  * Thread Sanitizer, a data race detector (TSan; `-fsanitize=thread`)

    <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>

  * Undefined Behavior Sanitizer (UBsan; `-fsanitize=undefined`)

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 from a
first look they reimplement a lot of [[/glibc]] by directly using
[[system_call]]s -- which is basically a no-go on GNU Hurd.


# 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

[[!message-id "20150414130851.GA6154@type.bordeaux.inria.fr"]].