Load a new exe with gdb - gdb

I am currently trying to make use of gdb to disassemble an exe, and from my home, I start the application like such:
gdb "c:\file.exe"
And gdb starts and loads that file automatically.
Now the problem is that from where I am atm, the command prompt is disabled and thus I cannot run the terminal window with the filename as the argument.
The only thing I think can do atm is open the gdb.exe file directly and then load the exe with a command or something, from gdb itself.
Is there a command I can use to load the exe to debug from within the application itself rather than passing it as an argument?
(gdb) <some command> "c:\file.exe"

(gdb)file c:\file.exe

To start debugging it , use the file command, as #Arkaitz Jimenez said
If your file.exe is a running process, you can use the attach command

Related

C++ lldb debug with input file

I'm attempting to debug my program with lldb beacuse I'm getting a segmentation fault when entering a specific input that should would. I give my program the input through a text file and normally I write this command to run it:
./program <tests/test1.maze> program.out
How do I run the debugger whilst still passing in the file? Haven't been able to find anything that says how to do this.
(lldb) process launch -i <file>
Use the help command to view all available options.
(lldb) help process launch

Xcode 8.3: Run target with input from file

I wrote a simple C++ program that requires some input to run. In the terminal I simply run in ./myProgram < fileWithData.txt. However I could not figure out how to specify and input file for the target executed in Xcode. I used the command line project. Of course I could use a different target, for example run Terminal.app and then pass it the executable with the input file but then I can no longer debug it.
This question: Cannot get lldb to read file input explains how to set the input path in lldb, but I could not find a way to specify lldb commands that are executed before the process is started.
I don't think there's a way to do this entirely from within Xcode. However if you set the Run Scheme in Xcode to the launch mode "Wait for executable to be launched," hit run, and then run your program from Terminal.app with the appropriate piping, the Xcode-embedded lldb will connect to it.

How to run a linux script before launching gdb debugging in Eclipse

How do I give commands to run before starting gdb debugging in Eclipse ?
Actually I want to execute few scripts that set environment variables (export vars) and execute a bunch of other programs before gdb process is launched from eclipse to debug my program.
I tried doing the following in debugger tab option:
<command> && <path-to-gdb-executable>
But I got the error that eclipse cannot execute gdb as given in above statement.
Please help - I actually want to execute a script called "before-launch-commands.sh" before debugging is started by gdb. I am trying to execute a cpp program under eclipse kepler.
Thanks.
The Eclipse Debug Configurations can already setup environment variables for you. I'm going to assume that that isn't sufficient, or you'd have already done it.
The first thing to do is create a new script, wrapped-gdb.sh:
#!/bin/sh
# Export any variables we need.
# Note that '.' (dot) is like an "include" statement.
. /path/to/before-launch-commands.sh
# Run GDB using the parameters passed in
exec /path/to/gdb "$#"
Next, set that script executable:
chmod +x /path/to/wrapped-gdb.sh
Finally, go to the Debugger tab in the debug configuration dialog, and in the box marked "GDB Debugger" enter /path/to/wrapped-gdb.sh.
When you launch your debug session it should now Do The Right Thing.

How to load extra libraries for GDB?

I'm trying to debug a CUDA program, but when I'm launching gdb like so:
$ gdb -i=mi <program name>
$ r <program arguments>
I'm getting:
/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw:
error while loading shared libraries: libcudart.so.5.0:
cannot open shared object file: No such file or directory
Process gdb-inferior killed
(formatted for readability)
(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
error while loading shared libraries: libcudart.so.5.0
This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.
In any case, this:
(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run
should fix this problem.
Update:
as I've mentioned it before, ld path is set properly
No, it isn't. If it was, you wouldn't have the problem.
Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).
If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.
I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).
I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.
gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:
(gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
(gdb) run
I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.
gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.

What needs to be done to get a distributable program from Eclipse?

I’ve produced a C++ program in Eclipse running on Redhat, which compiles and runs fine through Eclipse.
I thought that to run it separately to Eclipse you use the build artifact which is in the directory set via the project’s properties.
However this executable doesn’t run (I know it’s an executable as I’ve set it to be an executable via the project’s properties and it shows up as such via the ls command and the file explorer).
When attempting to run it using the executable’s name, I get the error:
bash: <filename>: command not found
When attempting to run it as a bash file:
<filename>: <filename>: cannot execute binary file
And when running it with "./" before the file name, nothing happens. Nothing new appears in the running processes and the terminal just goes to the next line as though I’d just pressed enter with no command.
Any help?
You've more or less figure out the first error yourself. when you just run <filename> , it is not in your PATH environment variable, so you get "command not found". You have to give a full or relative path when to the program in order to run it, even if you're in the same directory as the program - you run it with ./<filename>
When you do run your program, it appears to just exit as soon as you start it - we can't help much with that without knowing what the program does or see some code.
You can do some debugging, e.g. after the program just exits run echo $? to see if it exited with a particular exit value, or run your program using the strace tool to see what it does (or do it the usual way, insert printf debugging, or debug it with gdb)