rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 64 deletions

diff --git a/open_issues/_san.mdwn b/open_issues/_san.mdwn
deleted file mode 100644
index 5e6c8796..00000000
--- a/open_issues/_san.mdwn
+++ /dev/null
@@ -1,64 +0,0 @@
-[[!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