I am using gdb to debug a fortran90 program, myprog.f90, that uses some modules, say mod1 and mod2.
I launch gdb...
$ gdb ./program
and try to set a line break...
(gdb) break 80
but I receive the error "No line 80 in file 'mod1.f90'".
So although I am trying to set a line break in myprog.f90, it's trying to set the line break in the first module of the program mod1.
How do I break a line in and step through myprog.f90?
Thank you.
Do this:
(gdb) break myprog.f90:80
See also documentation on setting breakpoints, and on location specification.
Related
I am debugging a while loop using conditional breakpoints in gdb. There are multiple large arrays that are getting created in while loop. I would like to print them in a file while debugging so that I can compare using diff later.
I am able to visualize content at the console using the following command :
(gdb) p *&ff[0]#10
where ff is my array. Kindly tell how I can redirect them to text file.
You can use:
(gdb) set logging file large_array.txt
(gdb) set logging on
By default the logging file name is gdb.txt
You can find more details at: https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.html
There is also one WA gdb --args a.out arg1 ... |& tee gdb_out.txt
You set logging by using
(gdb) set logging on
after this, all command output will be output in a file called "gdb.txt". You can find the array content in the file.
How do you run GDB while allowing interactive entry of characters from the command line while simultaneosuly "printing" the values of the variables arising from the parsed characters from those entries?
In other words how do I run gdb, enter text into the command line AND see how the executable treats those entries?
Also is there any difference in the behavior of gdb if I run it from within Emacs with M-x gdb? Suspending the executable with C-c C-c and then trying to print variable values does not behave like I expected. It did not seem to recognize valid variable values from the suspended executable being debugged. I did generate a "debuggable" excutable from Clang with -ggdb -O0 flags.
I also tried to link gdb to the pid of the program executable running in a separate terminal but still am having difficulty with it. The program needs to parse command line entries interactively; I cannot pass them as initial command line arguments.
I hope I made my question clear.
After you started M-x gdb enter M-x gdb-many-windows . This opens new windows in your frame which show the stack, breakpoints, locals, your code and I/O of your program, meaning if you type there the input will be given to your executable.
I use openSUSE as my OS,and gdb 7.5. I want to debug my programs with gdb, with breakpoints. But when I make a breakpoint, and then run my program, gdb informs me as follows :
Error in re-setting breakpoint 1: malformed linespec error: unexpected string, ".cpp"
Its same in all of my programs. Also, when run to the breakpoint ,the program doesnt' stop at all. Can any one tell me what's wrong?
I download the latest gdb and install it ,the former message is gone ,but when run gdb it tells me that :
warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"?
how to slove this problem?
There is a known bug in gdb 7.5 where the debugger fails to parse the linespec when the source file name starts with a decimal digit. See this message for details.
Try renaming the file and update gdb from your distribution repository. If the bug persists, file a bug with your distribution maintainers.
See a sample session from a bug report submitted to gdb bugzilla.
(gdb) b 3
Breakpoint 1 at 0x4004c3: file 2.c, line 3.
(gdb) r
Starting program: /home/teawater/tmp/a.out
Error in re-setting breakpoint 1: malformed linespec error: unexpected string, ".c"
Error in re-setting breakpoint 1: malformed linespec error: unexpected string, ".c"
Error in re-setting breakpoint 1: malformed linespec error: unexpected string, ".c"
Error in re-setting breakpoint 1: malformed linespec error: unexpected string, ".c"
I use "b + linenumber"
This defines a breakpoint relative to the current line, see als Specifying a Location. With the code from your comment below, the following would work:
$ gdb ./main
(gdb) b +5
Breakpoint 1 at 0x40139c: file main.cpp, line 6.
(gdb) run
[New Thread 1528.0x1930]
Breakpoint 1, main () at main.cpp:5
5 while(scanf("%d%d",&a,&b)!=EOF)
Unless there is a good reason to specify relative line numbers, I suggest that you use absolute line numbers or function names:
(gdb) b main
Breakpoint 1 at 0x401395: file main.cpp, line 3.
(gdb) b main.cpp:6
Breakpoint 1 at 0x40139c: file main.cpp, line 6.
I run GDB on object file (e.g exeFile) and I want to examine it according to several commands . How can I execute these commands according to lines in a file (instead input these each GDN running) ?
For example -
I want to set break in -
break *0x8048e19
break *0x8048e32
break *0x8048e6f
break *0x8048e90
so I want to save them in a file and then tell the GDB execute them from this file.
write the commands in a file and execute gdb with -x switch
gdb -x command_file_name
or run the gdb source command while gdb is running if you dont want to specify a command file from command line
>source [-s] [-v] command_file_name
I am a beginner and got some trouble in RE.
I have an ELF 'bomb' and an unknown file 'model.abc'.
The correct way to run bomb is:
bomb model.abc
Now I want to use gdb to see the value of some addresses when running it. Can any one help me?
First start gdb from a shell prompt:
$ gdb bomb
Then run your program from the (gdb) prompt with the command line you want:
(gdb) run model.abc
You need to launch your program this way because gdb doesn't allow you to specify command line arguments for your program on the gdb command line.
Another, more convenient way of debugging a program with arguments:
gdb --args program <arguments>
If you don't have symbols, you'll have to start from the entry point. To figure our where it is, use:
(gdb) info file
Symbols from "/.../tesprog".
Local exec file:
`/.../tesprog', file type elf32-i386.
Entry point: 0x804abc0
Then you can set breakpoint on it before running:
break *0x804abc0
Note that the entry will be most often the library startup code (ctr0.s), it might take a while to get to the actual code written by the programmer.