2013-09-30 14:07:10 +02:00
|
|
|
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:
|
|
|
|
|
2013-10-24 12:58:28 +02:00
|
|
|
CFLAGS="-DHAVE_VALGRIND_VALGRIND_H" make
|
2013-09-30 14:07:10 +02:00
|
|
|
|
|
|
|
That way native can tell valgrind about RIOTs stacks and prevent
|
|
|
|
valgrind from reporting lots of false positives.
|
|
|
|
|
2013-10-24 12:58:28 +02:00
|
|
|
Usage:
|
|
|
|
Simply pass the ordinary command to valgrind like this:
|
|
|
|
|
|
|
|
valgrind ./bin/RIOT.elf tap0
|
|
|
|
|
|
|
|
This will yield some information whenever valgrind 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:
|
|
|
|
|
|
|
|
valgrind --db-attach=yes ./bin/RIOT.elf tap0
|
|
|
|
|
|
|
|
Now, you will be asked whether you would like to attach the running
|
|
|
|
process to gdb whenever a problem occurs.
|
|
|
|
|
|
|
|
In order for this to work under Linux 3.4 or newer, you might need to
|
|
|
|
disable the ptrace access restrictions:
|
|
|
|
As root call:
|
|
|
|
|
|
|
|
echo 0 > /proc/sys/kernel/yama/ptrace_scope
|
2013-09-30 14:07:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
NETWORK SUPPORT
|
|
|
|
===============
|
|
|
|
|
2013-08-08 11:08:33 +02:00
|
|
|
If you compile RIOT for the native cpu and include the native_net
|
2013-06-26 23:29:09 +02:00
|
|
|
module, you need to specify a network interface like this:
|
2013-10-24 12:58:28 +02:00
|
|
|
|
|
|
|
./bin/default-native.elf tap0
|
2013-06-26 23:29:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
SETTING UP A TAP NETWORK
|
|
|
|
========================
|
|
|
|
|
|
|
|
There is a shellscript in RIOT/cpu/native called tapsetup.sh which you
|
|
|
|
can use to create a network of tap interfaces.
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
To create a bridge and two (or count at your option) tap interfaces:
|
2013-10-24 12:58:28 +02:00
|
|
|
|
|
|
|
./tapsetup.sh create [count]
|
|
|
|
|
2013-06-26 23:29:09 +02:00
|
|
|
To delete the bridge and all tap interfaces:
|
2013-10-24 12:58:28 +02:00
|
|
|
|
|
|
|
./tapsetup.sh delete
|
2013-06-26 23:29:09 +02:00
|
|
|
|
|
|
|
|
2013-10-09 15:00:51 +02:00
|
|
|
OSX TAP NETWORKING
|
|
|
|
==================
|
2013-06-26 23:29:09 +02:00
|
|
|
|
|
|
|
For tun/tap networking in OSX you will need:
|
|
|
|
http://tuntaposx.sourceforge.net/
|
|
|
|
|
2013-08-15 17:04:03 +02:00
|
|
|
For OSX there is a seperate script called tapsetup-osx.sh.
|
|
|
|
Run it, (it instructs you to start the RIOT instances).
|
|
|
|
In contrast to linux you will need to run 'tapsetup-osx.sh delete'
|
|
|
|
after killing your instances and rerun 'tapsetup-osx.sh create' before
|
|
|
|
restarting.
|
|
|
|
Packet delivery under OSX only works with user assistance at the
|
|
|
|
moment. run 'kill -SIGIO <RIOT process ID>' to deliver a packet to a
|
|
|
|
specific RIOT instance.
|