summaryrefslogtreecommitdiff
path: root/open_issues/code_analysis.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/code_analysis.mdwn')
-rw-r--r--open_issues/code_analysis.mdwn177
1 files changed, 177 insertions, 0 deletions
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
new file mode 100644
index 00000000..a73f102c
--- /dev/null
+++ b/open_issues/code_analysis.mdwn
@@ -0,0 +1,177 @@
+[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
+
+In the topic of *code analysis* or *program analysis* ([[!wikipedia
+Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
+static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
+article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
+desc="Wikipedia article"]]). This topic overlaps with [[performance
+analysis|performance]], [[formal_verification]], as well as general
+[[debugging]].
+
+[[!toc]]
+
+
+# Bounty
+
+There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
+
+
+# Static
+
+ * [[GCC]]'s warnings. Yes, really.
+
+ * GCC plugins can be used for additional semantic analysis. For example,
+ <http://lwn.net/Articles/457543/>, and search for *kernel context* in
+ the comments.
+
+ * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out*
+ specifiers, and have it emit useful warnings in case these are pointing
+ to uninitialized data (for *in* only).
+
+ * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If
+ these are used, care must be taken to update them reliably, [[!message-id
+ "1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a
+ static analysis tool.
+
+ * [[!wikipedia List_of_tools_for_static_code_analysis]]
+
+ * [Engineering zero-defect software](http://esr.ibiblio.org/?p=4340), Eric
+ S. Raymond, 2012-05-13
+
+ * [Static Source Code Analysis Tools for C](http://spinroot.com/static/)
+
+ * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)
+
+ For example, [Debian's hurd_20110319-2
+ package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
+ (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
+ the realloc issues are for real*).
+
+ * Coccinelle
+
+ * <http://lwn.net/Articles/315686/>
+
+ * <http://www.google.com/search?q=coccinelle+analysis>
+
+ * [clang](http://www.google.com/search?q=clang+analysis)
+
+ * [Linux' sparse](https://sparse.wiki.kernel.org/)
+
+ * <http://klee.llvm.org/>
+
+ * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>
+
+ * [Smatch](http://smatch.sourceforge.net/)
+
+ * [Parfait](http://labs.oracle.com/projects/parfait/)
+
+ * <http://lwn.net/Articles/344003/>
+
+ * [Saturn](http://saturn.stanford.edu/)
+
+ * [Flawfinder](http://www.dwheeler.com/flawfinder/)
+
+ * [sixgill](http://sixgill.org/)
+
+ * [s-spider](http://code.google.com/p/s-spider/)
+
+ * [CIL (C Intermediate Language)](http://kerneis.github.com/cil/)
+
+ * [Frama-C](http://frama-c.com/)
+
+ * [Coverity](http://www.coverity.com/) (nonfree?)
+
+ * [Splint](http://www.splint.org/)
+
+ * IRC, freenode, #hurd, 2011-12-04
+
+ <mcsim> has anyone used splint on hurd?
+ <mcsim> this is tool for statically checking C programs
+ <mcsim> seems I made it work
+
+
+# Dynamic
+
+ * [[community/gsoc/project_ideas/Valgrind]]
+
+ * glibc's `libmcheck`
+
+ * Used by GDB, for example.
+
+ * Is not thread-safe, [[!sourceware_PR 6547]], [[!sourceware_PR 9939]],
+ [[!sourceware_PR 12751]], [[!stackoverflow_question 314931]].
+
+ * <http://en.wikipedia.org/wiki/Electric_Fence>
+
+ * <http://sourceforge.net/projects/duma/>
+
+ * <http://wiki.debian.org/Hardening>
+
+ * <https://wiki.ubuntu.com/CompilerFlags>
+
+ * `MALLOC_CHECK_`/`MALLOC_PERTURB_`
+
+ * IRC, freenode, #glibc, 2011-09-28
+
+ <vsrinivas> two things you can do -- there is an environment
+ variable (DEBUG_MALLOC_ iirc?) that can be set to 2 to make
+ ptmalloc (glibc's allocator) more forceful and verbose wrt error
+ checking
+ <vsrinivas> another is to grab a copy of Tor's source tree and copy
+ out OpenBSD's allocator (its a clearly-identifyable file in the
+ tree); LD_PRELOAD it or link it into your app, it is even more
+ aggressive about detecting memory misuse.
+ <vsrinivas> third, Red hat has a gdb python plugin that can
+ instrument glibc's heap structure. its kinda handy, might help?
+ <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.
+
+ * [`MALLOC_PERTURB_`](http://udrepper.livejournal.com/11429.html)
+
+ * <http://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719>
+
+ * In context of [[!message-id
+ "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue
+ mentioned in [[gnumach_page_cache_policy]]:
+
+ IRC, freenode, #hurd, 2012-07-08:
+
+ <youpi> braunr: there's actually already an ifdef REDZONE in libthreads
+
+ It's `RED_ZONE`.
+
+ <youpi> except it seems clumsy :)
+ <youpi> ah, no, the libthreads code properly sets the guard, just for
+ grow-up stacks
+
+ * GCC's AddressSanitizer, 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/>.
+
+ Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].
+
+ * GCC's ThreadSanitizer, a data race detector (TSan; `-fsanitize=thread`)
+
+ <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>
+
+ Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].
+
+ * Input fuzzing
+
+ Not a new topic; has been used (and a paper published) for early UNIX
+ tools, I[[I|tschwinge]]RC.
+
+ * <http://caca.zoy.org/wiki/zzuf>
+
+ What about some [[RPC]] fuzzing?