1 files changed, 64 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/_san.mdwn b/service_solahart_jakarta_selatan__082122541663/_san.mdwn
new file mode 100644
index 00000000..5e6c8796
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/_san.mdwn
@@ -0,0 +1,64 @@
+[[!meta copyright="Copyright © 2012, 2013 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]]
+
+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