native readme update

cpu/native/README

@@ -1,28 +1,25 @@
 VALGRIND SUPPORT
 ================
 
-If you want to use valgrind, you should recompile native with either
-HAVE_VALGRIND_H or HAVE_VALGRIND_VALGRIND_H depending on the location
-of the valgrind header (i.e. <valgrind.h> or <valgrind/valgrind.h>)
-like this:
-
-    CFLAGS="-DHAVE_VALGRIND_VALGRIND_H -g" make
+Rebuild your project using the all-valgrind target like this:
+
+    make -B clean all-valgrind
 
 That way native will tell valgrind about RIOTs stacks and prevent
 valgrind from reporting lots of false positives.
 The debug information flag "-g" is not strictly necessary, but passing
 it allows valgrind to tell you precisely which code triggered the error.
 
-Usage:
-Simply pass the ordinary command to valgrind like this:
+To run your application run:
 
-    valgrind ./bin/native/default.elf tap0
+    make valgrind
 
-This will yield some information whenever valgrind detects an invalid
-memory access.
+All this does is run your application under valgrind.
+Now valgrind will print some information whenever it detects an
+invalid memory access.
 
 In order to debug the program when this occurs you can pass the
---db-attach parameter to valgrind like this:
+--db-attach parameter to valgrind. E.g:
 
     valgrind --db-attach=yes ./bin/native/default.elf tap0
 
@@ -35,9 +32,13 @@ As root call:
 
     echo 0 > /proc/sys/kernel/yama/ptrace_scope
 
-Another helpful valgrind parameter is "--track-origins=yes" which
-will allow valrgind to tell you where references to uninitialized
-values stem from.
+PS:
+If the all-valgrind make target fails you might have to adjust the
+headers path. Change the parameter in boards/native/Makefile.include
+from HAVE_VALGRIND_VALGRIND_H to HAVE_VALGRIND_H to resolve the
+situation locally and open an issue to get it resolved permanently. (I
+have not yet encountered a platform that actually uses the other
+header path.)
 
 
 NETWORK SUPPORT