Return to lldb prompt when debugging interactive command-line program - lldb

I'm debugging an interactive, command-line program with lldb. The program presents its own prompt to the user (in a manner similar to fdisk).
My question is, how do I escape, or get back to, the lldb prompt while I'm executing the program?
Here's how I go about launching the program and getting to the point that I'm inquiring about:
bash$ lldb progname progarg1
(lldb) target create "progname"
Current executable set to 'progname' (x86_64).
(lldb) settings set -- target.run-args "progarg1"
(lldb) process launch
Process launched Process 29286 launched: '/home/chb/progdir/progname' (x86_64)
progname>help
Commands are:
buy: use schmeckles to buy a plumbus
lube: rub with the fleeb
...
progname>
After entering the program's command loop, how do I get back to lldb to issue other, lldb-related commands?

Hitting Control-C on your keyboard interrupts the program and lldb takes control.

Related

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.

gdb: debug line by line with pipe

If I want to debug my program I call it like this:
gdb ./myprog
$ run < input.txt
But now I want to execute it line by line, but how can I do this? I know the step command but I can only call it, if the run command was called before. Do I have to stop the execution directly after the run command?
Gdb has a start command, which takes the same arguments as the run command. After starting the program, it stops as soon as possible, usually at the start of the main function. After that, you can use the step command and any other commands that require a live process.
Reference: Debugging with GDB: Starting your Program

Unable to input data to C program while debugging in separate terminal with gdb & tty command

I am debugging a C program with gdb. I have used the tty command to send the output to a new terminal window but am unable to enter input while the program is running.
If I debug in the same window it works fine, but when using a separate terminal window, input doesn't do anything.
I can still kill the process with ctr-c but once I hit the input line, it waits for input and doesn't do anything when I press return.
I have looked around but am haven't found the same problem online. Any ideas?
Start your program in one window. While your program is waiting for input, start gdb in another window. Use the gdb attach command to attach to and debug your program.

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

Opening a new terminal window & executing a command

I've been trying to open a new terminal window from my application and execute a command on this second window as specified by the user. I've built some debugging software and I would like to execute the user's program on a separate window so my debugging output doesn't get intermixed with the programs output.
I am using fork() and exec(). The command I am executing is gnome-terminal -e 'the program to be executed'.
I have 2 questions:
Calling gnome-terminal means the user has to be running a gnome graphical environment. Is there a more cross-platform command to use (I am only interested in Linux machines though)?
After the command finishes executing the second terminal also finishes executing and closes. Is there any way to pause it, or just let it continue normal operation by waiting for input?
You probably want something like xterm -hold.
1) gnome-terminal should work reasonably also without the whole gnome environonment, anyway the old plain "xterm" is enough.
2) you can execute a short bash script that launch your program and at the end reads a line:
bash -c 'my program ... ; read a'
(or also 'xterm -e ...')

Resources