I want to give ocamldebug a try. How can I run a program in it with a set of arguments? I can't find anything related in the reference documentation.[1]
In GDB, I would enter run arg1...argn. Unfortunately it doesn't seem to work in ocamldebug.
$ ocamldebug server.byte
OCaml Debugger version 4.04.0
(ocd) run -i 127.0.0.1 -p 8080
Syntax error.
(ocd)
Entering help run doesn't give much information:
(ocd) help run
run: run the program from current position.
https://caml.inria.fr/pub/docs/manual-ocaml/debugger.html
From docs:
ocamldebug [options] program [arguments]
The arguments following program are optional, and are passed as
command-line arguments to the program being debugged. (See also the
set arguments command.)
In debugger, you can use set arguments -i 127.0.0.1 -p 8080 command.
Related
I am trying to launch a legacy application in GDB, and it requires that it's argv[0] value not contain anything other than alphanumeric characters.
Whenever I launch the program in GDB it seems that it expands the name to be the full path before running the program, so I get an error like (because it can't deal with the slashes):
"Cannot find /home/user/myapp ..."
Is it possible to run a program in GDB with a relative path, so that it will just see "myapp"?
Gdb normally runs target commands using the shell command line
exec program_pathname program_arguments
But it has a set exec-wrapper command that will change this to
exec exec_wrapper program_pathname program_arguments
The exec_wrapper is often another command, but it can be an option that the exec command accepts.
Many shells (bash, zsh, ksh93) support a -a option to the exec command to set argv[0].
So, if your shell supports exec -a, you can do the following to invoke /home/user/myapp with argv[0]==myapp:
(gdb) set exec-wrapper -a myapp
I'm receiving this gdb error on any code I try to debug any program with gdb. Here's the simplest process that reproduces the error
Create a main.cpp file with this content:
int main(){
return 0;
}
Run g++ -g main.cpp
Run gdb a.out
Inside gdb set a break point at line 2 with break 2
In gdb run the program with run
Output:
Starting program: /tmp/test/a.out
During startup program exited normally.
This is all done with gdb on the command line. I've tried using g++ and gcc with the same result. I'm not really sure where to go from here.
gdb version = 9.2
g++ version = 9.3.0
EDIT: I figured out what is causing the issue, but not how to fix it. The issue seems to be something related to my SHELL variable. I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
This might be your xonsh startup problem, or it might be xonsh problem, or it could be that xonsh doesn't do what GDB expects it to do.
Normally, GDB forks / execs $SHELL -c "/path/to/your/exe $args" and expects the $SHELL to exec your program (this is done so shell redirection still works under GDB).
Only after that exec will GDB start setting breakpoints, etc.
If you have some xonsh init-file, which e.g. causes xonsh to exec something else, things could go bad. So I suggest trying to remove any such ~/.xonshrc or whatever it's called file, and seeing whether that fixes the problem.
If it doesn't, it could be that xonsh e.g. forks and execs your binary in a child (grandchild of GDB) instead of doing it directly, or it could be that xonsh doesn't understand the -c ... syntax.
If you don't care about redirection, you could also ask GDB to not use $SHELL at all: set startup-with-shell off. Documentation.
Background info: The C++ program(LAMMPS - an open source) takes in a input script that has all the commands to be executed. The executable is named "lmp_fedora", input script named "in.hit". The program's run command "./lmp_fedora < in.hit"
My Problem: I am trying to debug one of the .cpp files in LAMMPS.
My Attempts: 1. I tried "gdb lmp_fedora < in.hit", but it failed. 2. Also tried to find the pid of the running program using ps aux, but wasn't sure which id it was.
My Question: How do you debug a input script(that has commands linked to c++ project) using gdb?
You use the gdb run command:
$ gdb lmp_fedora
(gdb) run <in.hit
From the help:
(gdb) help run
Start debugged program. You may specify arguments to give it.
Args may include "*", or "[...]"; they are expanded using "sh".
Input and output redirection with ">", "<", or ">>" are also allowed.
With no arguments, uses arguments last specified (with "run" or "set args").
To cancel previous arguments and run with no arguments,
use "set args" without arguments.
When you say gdb foo < bar that means bar is input to gdb, not to foo.
I think what you want to use is the gdb command set args.
I tried the following code, to communicate with the command line from c++ code.
#include<iostream>
#include<cv.h>
int main()
{
system("gnome-terminal");
system("cd");
}
The gnome-terminal command is executing fine. After I close the terminal, when am expecting the cd to execute, however, is not happening. Could you please help me and point out the reason? Thanks. I was expecting the function to make the cmd go down to the home directory
, but it did not. am working in linux
I tried it even by removing gnome. simple cd is not working. am I doing something rong>?
If I try ls, it seems to be working fine!
My main aim is to open a new terminal, and execute commands on that new terminal through the present program that opened the new terminal. Could you please tell me how I can achieve this??
If you want to run a program and wait for it to finish before executing next line, take a look at this page and example code here: http://www.thegeekstuff.com/2012/03/c-process-control-functions/
But if you want to run gnome-terminal and execute a command in newly created window, do this:
system("gnome-terminal -x sh -c 'cd /tmp ; ls -la'");
The system function creates a shell child process to execute the specified command.
cd is a shell command which changes the current working directory of that shell process only.
So the child's cd probably works fine, but it has no effect on your C++ program, which is a different process.
Instead, you probably want to look at the Linux system call chdir.
Thanks for your help!! This command worked perfectly fine from this link
https://superuser.com/questions/198015/open-gnome-terminal-programmatically-and-execute-commands-after-bashrc-was-execu
gnome-terminal -x sh -c 'command1; command2; exec bash'
and I entered the respective commands in the new window. But to change the working directory in the shell am working o, I haven't still figured that out.
I have a program using LD_PRELOAD. The program should be run like
this, "LD_PRELOAD=/path/to/libfoo.so qemu -U LD_PRELOAD a.out", if
without gdb.
Here are what I did while running gdb.
(gdb) set environment LD_PRELOAD=/nfs_home/chenwj/tools/lib/libdbo.so
(gdb) file /nfs_home/chenwj/tools/bin/qemu-i386
(gdb) r -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1
But gdb gave me the error below
Starting program: /nfs_home/chenwj/tools/bin/qemu-i386 -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1
bash: open "/bin/bash" failed: Permission denied
During startup program exited with code 66.
Any sugguestion appreciated.
Regards, chenwj
GDB does not invoke your executable directly. Instead, it does
bash -c '/nfs_home/chenwj/tools/bin/qemu-i386 -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1'
This is done so that bash takes care of I/O redirection (which you are not using).
My guess is that /bin/bash doesn't work when LD_PRELOAD=libdbo.so is in effect, though I don't understand the exact nature of failure.
One way to work around this problem is to create a wrapper executable, implementing C equivalent of this:
export LD_PRELOAD=/nfs_home/chenwj/tools/lib/libdbo.so
exec /nfs_home/chenwj/tools/bin/qemu-i386 "$#"
and debug that executable (without setting LD_PRELOAD). You'll see an extra SIGTRAP when the wrapper execve()s the wrapped qemu-i386, which you should ignore and continue.