community/gsoc/project_ideas/gcc_asan -> open_issues/_san.
[hurd-web.git] / community / gsoc / project_ideas / gcc_asan.mdwn
diff --git a/community/gsoc/project_ideas/gcc_asan.mdwn b/community/gsoc/project_ideas/gcc_asan.mdwn
deleted file mode 100644 (file)
index 21a3066..0000000
+++ /dev/null
@@ -1,46 +0,0 @@
-[[!meta copyright="Copyright © 2012 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 GCC's AddressSanitizer to the Hurd"]]
-
-[[!tag open_issue_gcc]]
-
-See the entry on the [[open_issues/code_analysis]] page.
-
-See also the [[valgrind]] task.
-
-A follow-up project is porting GCC's ThreadSanitizer.
-
-Possible mentors: Thomas Schwinge (tschwinge)
-
-
-# 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