start gdb using a pid - c

In general i see the process's pid which is running in the background and start dbx on that process using the command dbx -a <pid>
similarly how could i do it using gdb?

In addition to the previous you can directly use
gdb -p <pid>

There are two ways.
From the command line, include the pid as an argument after the executable name:
gdb /path/to/prog PID
From within gdb, you can use the attach command:
gdb /path/to/prog
gdb> attach PID
While the specifying on the command line is more concise, there is a slight risk that if you have a core file that has a name that is the same as the pid (i.e. for pid 2345, the core file would have to be named "2345") then gdb will open the core file. Admittedly, the chance of this happening is minuscule.

From the gdb man page:
You can, instead, specify a process ID as a second argument, if you want to debug a running process:
gdb program 1234

Related

How to prevent GDB from exiting when reaching execve?

Currently debugging a tcsh like remake, I used :
set follow-fork-mode child
to follow a child program after fork but reaching the execve system call GDB exit and I got the following message :
process 11217 is executing new program: /usr/bin/cat
zsh: suspended (tty output) gdb ./mysh
How can I prevent that ?
Thanks you in advance !
Looks like the child got suspended?
You can let the child run with:
set detach-on-fork on
This is the default. You can check with show detach-on-fork whether it's been turned off (perhaps via .gdbinit?).
To follow the exec'ed process, you can use:
set follow-exec-mode new
You can also switch between multiple processes using inferior. First get inferior numbers via:
info inferiors
Then to switch:
inferior <num>

Cannot get mac os x lldb process to read the STDIN

Is it me or lldb for mac os x (replacing gdb) does not allow you to pipe a file into the stdin, to be used by the process being debugged?
reading the instructions there is no reference to it.
I've gone through and installed gnu gdb, but would like to take advantage of what I suppose is improved lldb capability?
(lldb) process launch -i <file>
Should do the trick. Note you can't say:
(lldb) run -i <file>
since run is an alias for process launch -- so all its arguments are passed to the process being launched.
There's a general "help" facility that can show you more about all the lldb commands.
(lldb) help process launch
would have shown you this option.

Why I can't see my process which is created fork function in linux top command

I have a C program which creates processes with fork() and prints pid of them with get_pid(). While this program is running, I use "top" command to see same processes, but I can't see them in there. Why? and how I can see my processes with "top" command?
top sorts according to a field, by default this is cpu time
your C program is probably too small and efficient to show up in the list
to see similar metrics to top but for a specific pid use ps, for example
ps -lp 12188
I'm with #Vorsprung. You may also note that you can use top with a pid argument:
top -p PID

set breakpoint in the process started by other process

I am faced with a situation wherein I have process X executing a
a command ( say /bin/ls ). as soon as the process X executes the command ls
I want to put a breakpoint in a function in ls.
Is there any way to do this ?
An easy solution may be to wrap the binary in question (that is called by process X) in a small shell script that starts the process in a debug session and applies pre-configured breakpoints as well.
I can think of two ways to do it.
Simplest is to set follow-fork-mode child whenever new new client process is created GDB will debug the child. However with this mode you will not be able to debug the parent process any more.
In the child process (ls mentioned above) add some code to wait for a signal say SIGCONT at the very beginning. Whenever child process is created attach GDB (new GDB instance) to it with its PID of child process, issue the singnal SIGCONT to continue.
You can use catch exec [1] to stop on exec calls:
(gdb) catch exec
Catchpoint 1 (exec)
(gdb) r
Starting program: /tmp/a.out
process 7544 is executing new program: /bin/ls
Catchpoint 1 (exec'd /bin/ls), 0x00007ffff7ddfaf0 in _start () from /lib64/ld-linux-x86-64.so.2
Then you can do whatever you want with the new process. See also the link in the comment by dbrank0 for various fork-related options.

commands to gdb from C program

I am newbie to UNIX programs. I have encountered a situation wherein I have to issue commands to gdb from my C program. I have a C program which invokes another C program by forking a new child process. I need to debug this child C program and hence, I used system command to call gdb process on this C program. But I get a gdb prompt which I do not want. I want to issue commands to the gdb from my parent C program. Is there a way to issue commands to gdb from a C program ?
Please reply.
Thanks a lot.
Esash
If you need to debug the child process, you don't necessarily need to invoke the child with GDB when you fork+exec. As long as you have the PID of the child process, you can use the "attach" command in GDB to attach to the running child process. Basically, you would start GDB like:
$ gdb
(gdb) attach pid-of-child
In the above, replace pid-of-child with the PID of the child process, and there you go, you can debug the child process from interactive GDB, without the parent process needing to deal with GDB at all.
There are several ways to "drive" GDB programmatically.
If you just want to issue one command, e.g. to find out why the child crashed, you can do something like this:
gdb --batch -ex where /path/to/child <pid-of-child>
If there are more commands then you are willing to put on command line, you could write them to a temporary file, and ask gdb to execute them:
gdb --batch -x /path/to/commandfile /path/to/child <pid-of-child>
Neither of the above allows you to perform programmatic (if ... then do-something-in-gdb else do-something-else-in-gdb) control.
For that you may want to either exercise GDB's machine interface (MI), or use the embedded Python interpreter.
Theres also the follow on fork gdb option. This will attach to the child process immediately.
set follow-fork-mode mode
so,
set follow-fork-mode child

Resources