[[!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 hmm, is libtsan not multi-libbed? richi: it only works on x86_64 right now ugh richi: so, it is multilibbed, but only built on multilibs and targets which are supported richi: as it often needs lots of RAM, it is probably not going to be supported on 32-bit targets at all richi: no reason not to support it on say ppc64 or sparc64 or s390x I guess, just needs work jakub: where is asan supported? everywhere? 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 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) richi: porting isn't that hard, but the library isn't as clean as it would be desirable portability wise 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