Show gdb.asc syntax highlighted
Running gdb with multi-process Programs (and EmRun in particular)
=================================================================
The EmStar Team
$Id: gdb.asc,v 1.5 2006/04/24 20:35:33 girod Exp $
This is not intended to be a detailed guide to using gdb. However, I wanted to document my own experiences in the hope that it may be useful for others in the future.
EmRun operates by launching a number of different processes (as opposed to spawning threads) which means that you probably can't attach gdb to the process you are interested in at startup (since presumably most users will not be debugging EmRun itself). However, gdb does provide a mechanism to allow you to attach it to a running process, like this.
1) After starting EmRun with your desired run file, get the pid of the process you wish to attach to, either by examining the EmRun output, or by doing:
--------------
cat /dev/emrun/status
--------------
This returns (amongst other information) the pid of all spawned processes.
2) Run gdb
3) At the gdb prompt, type:
--------------
(gdb) attach <pid of process to attach to>
--------------
You can now set breakpoints, and debug as you normally would this spawned process
NOTE: You can debug as many different processes as you like, just start up a new gdb instance for each process you wish to debug.
This works fine if you are interested in 'steady-state' behaviour (in other words, it doesn't matter to you at which point in program execution you successfully attach to your running process). A command has been added that will allow you to direct EmStar to stop a process at startup time, allowing the user to manually perform the steps described above and catch my program before it has time to do anything interesting.
Simply add the directive '--stop-on-startup' to the list of command line options specified using the cmd function in your EmRun macro. For example, the cmd command may now look like:
-------
cmd = "$debug mote/hostmoted $args -p $port -m $type -r $index --stop-on-startup";
-------
///////////////////////////////////////////////////////
I removed this section because i found it to be more confusing than helpful..
it really only applies to debugging _emrun_ with gdb, which is something
almost nobody would ever need to do.... --LDG
I can also provide some tips on things not to do:
1) Be very careful when placing breakpoints in emrun/emrun/emrun_proc.c where processes are being spawned. There is some signal complexity in here which plays havoc with gdb, and may cause your program to crash.
2) Make sure you do not attach gdb to a process before the process context has been replaced by the call to execvp(...). Unsurprisingly, gdb does not handle this case, and it will crash itself and your program.
Another idea that doesn't quite work yet
----------------------------------------
A suggestion was made that code could be added to a child process so that the child would spawn another child process to run gdb, and attach gdb to itself. Below is some sample code to do that, although I was not able to figure out how to spawn gdb in a new terminal (I was also unable to create new terminals in this way - the terminal terminated itself as soon as it was spawned).
So in other words, this does work, but gdb runs in the original 'parent' terminal, which will no doubt cause problems if your parent process generates output text.
------------------
#include <sys/types.h>
#include <unistd.h>
int main()
{
int b;
pid_t pid = getpid();
char *arg_list[4];
char *arg_list1[4];
char str_to_attach1[1000];
char str_to_attach2[1000];
char file_name[1000] = "gdb";
arg_list[0] = &file_name[0];
arg_list[1] = &str_to_attach1[0];
arg_list[2] = &str_to_attach2[0];
arg_list[3] = NULL;
printf("I am process b, pid = %d\n", pid);
sprintf(str_to_attach1, "attach");
sprintf(str_to_attach2, "%d", pid);
pid = fork();
if (pid < 0)
{
perror("Unable to fork");
return -1;
}
if (pid == 0)
{
// this is the child - start gdb and attach to self
execvp("gdb", arg_list);
}
else
{
// this is the parent
while (1)
{
b = b+1;
if (b > 10000)
{
b = 0;
}
sleep(2);
}
}
return 0;
}
------------------
///////////////////////////////////////////////////////
See more files for this project here
EmStar is a software system for developing and deploying wireless sensor networks involving Linux-based platforms. As the wireless sensor network community has attempted to deploy more complex designs---large-scale, long-lived systems that need self-organization and adaptivity---a number of difficult software design issues have arisen. Advances in software design have not kept pace with the capabilities of hardware. This is because designing for an adaptive, efficient, and useful sensor network has turned out to be surprisingly complex and difficult. EmStar is a Linux-based software framework, whose goal is to dramatically reduce this complexity, enabling work to be shared and reused, and simplifying and speeding the design of new sensor network applications.
Project homepage:
http://cvs.cens.ucla.edu/emstar/
Programming language(s): C,Shell Script
License: other
misc/
queue.asc
building_an_array.asc
delay.asc
emcee.asc
emsim.asc
emtos.asc
events.asc
gdb.asc
http.asc
index.asc
link.asc
make.asc
misc.asc
node.info
prog_model.asc
run.asc
sim_component.asc