GDB is going backwards [duplicate] - c++

I am simply using gdb to step through a code line by line to learn how it is working and what it is doing. It worked fine the first time I did this, but now the next command is not working right. Sometimes it goes forward, sometimes it goes backwards. It doesn't make sense. Every time I do this it seems to be the same pattern. Below is an example. Anyone know what is wrong?
Note: This is an old Mac with old program versions (That I do not have the power to update)
Please be explicit. I am fairly new to linux and programming in general.
Thanks!
Reading symbols for shared libraries ... done
(gdb) b main
Breakpoint 1 at 0x2730: file ../../../../gcc-3.4.6/libf2c/libF77/pow_zi.c, line 14.
(gdb) r
Starting program: /Users/kevin/project/ConstU/main
nReading symbols for shared libraries +. done
Error in re-setting breakpoint 1:
Function "main" not defined.
Re-enabling shared library breakpoints: 1
Breakpoint 1, 0x00002730 in main () at main.c:34
34 {
(gdb) n
main () at main.c:42
42 for (i=0;i<DpDIM;i++) {
(gdb) n
34 {
(gdb) n
35 runstart=clock();
(gdb) n
39 Init=ReadInit(&CaseDim);/*reads in initial valies from initfile*/
(gdb) n
35 runstart=clock();
(gdb) n
39 Init=ReadInit(&CaseDim);/*reads in initial valies from initfile*/
(gdb)

Anyone know what is wrong?
The symptoms you've described are very common when debugging programs built with optimization: the compiler re-arranges code in such a way that instructions from different lines become intermixed.
Make sure you compile without any -O flags, or add -O0 at the end of your compilation lines.
here is part of the make file: CC = gcc CFLAGS = -g -O2
That would do it: remove -O2 and your debugging would go much easier.

Related

GDB error `../gcc-6.2.0/libgfortran/runtime/main.c: No such file or directory` [duplicate]

I have a Fortran program I am debuging. I have a list of varables and one of the expected variables is almost double its expected value.
So I compiled the program, with debug flags, and commenced debugging:
the program name is hfock
$gdb hfock
(gdb) break hfock
(gdb) run
Starting program: /home/e/Desktop/hfock hfock
Breakpoint 1, hfock () at hfock.f:16
16 ZETA1 = 2.173171
(gdb) s
17 ZETA2 = 1.188530
(gdb) s
18 WRITE (*, '( "Zeta1:", F7.4 / "Zeta2:", F7.4 )' ) ZETA1, ZETA2
(gdb) s
Zeta1: 2.1732
Zeta2: 1.1885
21 PLUS=ZETA1+ZETA2
(gdb) s
22 PROD=ZETA1*ZETA2
(gdb) s
23 DIFF=ZETA1-ZETA2
(gdb) s
24 S12=8.*PROD**1.5/PLUS**3
(gdb) s
__powf (x=2.58287883, y=1.5) at w_powf.c:26
26 w_powf.c: No such file or directory.
The corresponding (24,25,26) lines of code are:
S12=8.*PROD**1.5/PLUS**3
T11=0.5*ZETA1**2
T22=0.5*ZETA2**2
I think this might be a math library, or glibc related error, but I'm not sure what the error means, or how to fix it.This is fortran, why is it calling a C library? do I need to include a library? or install a missing dependency?
full program source here:
http://pastebin.com/waeEFSBZ
** is in Fortran exponential operator. Exponentiation is implemented in glibc w_powf.c. Gdb can't find this file in your sources. This is not an error, rather diagnostic.
The error means that the source file w_powf.c is not available on your system. It's not related to your program apparently. You can safely ignore that error.
Note that the lines you mention have the operator ** which I suppose is implemented in that file, so it's just telling you that there is no access to the source code of the implementation of that operator.

Higher line numbers are unresolved as breakpoints when debugging using lldb

I am trying to set breakpoints in a MIPS32r6 program that computes the Mandelbrot Set in Brainfsck. The program itself is written in C++, compiled with Clang, and I am debugging with LLDB.
The issue that I am having is that when in LLDB, I can set certain breakpoints, mainly on lower line numbers, with no issues. However, after Line #70 in Main.cpp, the breakpoints are coming up as 'unresolved' (even though executing breakpoint list shows them with completely reasonable addresses). That is to say, all breakpoints that I try to set after Line #70 are coming up as unresolved, and all reasonable breakpoints before Line #70 resolve without issue.
I've placed a copy of the binary that I've linked here: http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin
And a copy of Main.cpp here: https://paste.ee/p/WYs8Y
I am building with the following options:
clang -mcompact-branches=always -fasynchronous-unwind-tables -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
lld --discard-none -znorelro --eh-frame-hdr ...
At this point, I am unsure as to what might be causing this issue.
I'd try doing target modules dump line-table Main.cpp in lldb to see what lldb thinks the line table looks like. Then look at the binary's DWARF line table with something like readelf --debug-dump=decodedline MipsTest.bin (I think that's right - I'm looking at a readelf main page on the web).
Using your sample binary, I get:
(lldb) b s -l 72
Breakpoint 1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 0x000134a0
So we found an address for the breakpoint. If it is unresolved when you run, that means we weren't able to implement the breakpoint at that address (e.g. for some reason couldn't write the trap into the program memory there.)

g++4.8 hides variables from gdb

After recently upgrading to g++ 4.8.1 I've found that debugging is completely impossible in gdb. g++ seems to hide all variables from gdb, regardless of optimization options. In the following session, runner.cpp is as follows:
#include <vector>
using namespace std;
int main(void) {
vector<int> arr;
int a = 3;
int b = 2;
b = a + 3;
arr.push_back(1);
arr.push_back(2);
arr.push_back(3);
arr.push_back(4);
return 0;
}
This is the result:
Script started on Tue 14 Jul 2015 01:11:14 PM PDT
me#ministation:~/Development/clib$ g++ -g -O0 runner.cpp
me#ministation:~/Development/clib$ gdb -q ./a.out
Reading symbols from /home/me/Development/clib/a.out...done.
(gdb) break 11
Breakpoint 1 at 0x40095c: file runner.cpp, line 11.
(gdb) run
Starting program: /home/me/Development/clib/a.out
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
Breakpoint 1, main () at runner.cpp:11
11 arr.push_back(1);
(gdb) print a
$1 = {i = {0, 1045149306}, d = 1.2904777690891933e-08} ## I have no idea what this means
(gdb) print b
$2 = {i = {0, 1068498944}, d = 0.0625}
(gdb) print arr
No symbol "arr" in current context.
(gdb) info locals
No locals.
(gdb) next
12 arr.push_back(2);
(gdb)
13 arr.push_back(3);
(gdb) print arr
No symbol "arr" in current context.
(gdb) next
14 arr.push_back(4);
(gdb)
16 return 0;
(gdb) print arr
No symbol "arr" in current context.
(gdb) q
A debugging session is active.
Inferior 1 [process 6392] will be killed.
Quit anyway? (y or n) y
me#ministation:~/Development/clib$
Script done on Tue 14 Jul 2015 01:12:05 PM PDT
I've seen somewhat similar posts where the -O0 flag was recommended, but it doesn't seem to work here. The exact same session after compiling with g++4.6 produces the expected results. Any ideas on what's causing this with g++4.8?
The particular problem here is that the meaning of the DW_AT_high_pc tag in the debug info has been extended to also mean an offset.
Originally, a function ranging from 0x804dd8e to 0x804ddae was encoded as
DW_AT_low_pc : 0x804dd8e
DW_AT_high_pc : 0x804ddae
Now it also can be encoded as
DW_AT_low_pc : 0x804dd8e
DW_AT_high_pc : 0x20
which saves a bit of space in the debug info.
Older versions of GDB only recognize the first version, and interpret the second in a way that there can't be any variables in this range.
Possible solutions are to compile with -gdwarf-2 or to upgrade GDB.
gdb and gcc need to be compatible versions when it comes to debug format (and they are generally quite well compatible over many versions, but SOMETIMES compatibility is broken from one version of a compiler to another).
I have had exactly the same problem. The solution is either to throw some flag at gcc to compile with "older style debug format", or to upgrade the version of gdb to one that "works" with the debug format given by the newer version of gcc.
It would be NICE if gdb actually said something like "Your debug format is X, you need debug format Y or Z for gdb to work correctly", but I'm not 100% sure that can be reliably determined (for example when a bug is found in the generation that is fixed, and need the corresponding fix in the debugger, because the same bug appears in both the "produce" and "consume" parts of the debug-symbol handler - so an older, buggy version can't read the newer unbuggy format and vice versa)

next command in gdb is not working correctly

I am simply using gdb to step through a code line by line to learn how it is working and what it is doing. It worked fine the first time I did this, but now the next command is not working right. Sometimes it goes forward, sometimes it goes backwards. It doesn't make sense. Every time I do this it seems to be the same pattern. Below is an example. Anyone know what is wrong?
Note: This is an old Mac with old program versions (That I do not have the power to update)
Please be explicit. I am fairly new to linux and programming in general.
Thanks!
Reading symbols for shared libraries ... done
(gdb) b main
Breakpoint 1 at 0x2730: file ../../../../gcc-3.4.6/libf2c/libF77/pow_zi.c, line 14.
(gdb) r
Starting program: /Users/kevin/project/ConstU/main
nReading symbols for shared libraries +. done
Error in re-setting breakpoint 1:
Function "main" not defined.
Re-enabling shared library breakpoints: 1
Breakpoint 1, 0x00002730 in main () at main.c:34
34 {
(gdb) n
main () at main.c:42
42 for (i=0;i<DpDIM;i++) {
(gdb) n
34 {
(gdb) n
35 runstart=clock();
(gdb) n
39 Init=ReadInit(&CaseDim);/*reads in initial valies from initfile*/
(gdb) n
35 runstart=clock();
(gdb) n
39 Init=ReadInit(&CaseDim);/*reads in initial valies from initfile*/
(gdb)
Anyone know what is wrong?
The symptoms you've described are very common when debugging programs built with optimization: the compiler re-arranges code in such a way that instructions from different lines become intermixed.
Make sure you compile without any -O flags, or add -O0 at the end of your compilation lines.
here is part of the make file: CC = gcc CFLAGS = -g -O2
That would do it: remove -O2 and your debugging would go much easier.

How do I use the MinGW gdb debugger to debug a C++ program in Windows?

I have looked for documentation on this and found nothing. I have MinGW installed and it works great. I just don't know how to use the debugger.
Given some simple code, say in a file called "mycode.cpp":
int main()
{
int temp = 0;
for (int i = 0; i < 5; ++i)
temp += i;
return 0;
}
...how would I debug this. What are the commands that I use to debug code with MinGW and GDB in windows? Can I step through the code via the command line like in Visual Studio? If so what commands do I use to do that?
Are there any tutorials for using GDB out there? I couldn't find any, but if anyone could direct me to one that would be great too. I'm tired of writing tons of std::cout statements to debug complex code.
The first step is to compile your program with -g to include debugging information within the executable:
g++ -g -o myprog.exe mycode.cpp
Then the program can be loaded into gdb:
gdb myprog.exe
A few commands to get you started:
break main will cause the debugger to break when main is called. You can also break on lines of code with break FILENAME:LINENO. For example, break mycode.cpp:4 breaks execution whenever the program reaches line 4 of mycode.cpp.
start starts the program. In your case, you need to set breakpoints before starting the program because it exits quickly.
At a breakpoint:
print VARNAME. That's how you print values of variables, whether local, static, or global. For example, at the for loop, you can type print temp to print out the value of the temp variable.
step This is equivalent to "step into".
next or adv +1 Advance to the next line (like "step over"). You can also advance to a specific line of a specific file with, for example, adv mycode.cpp:8.
bt Print a backtrace. This is a stack trace, essentially.
continue Exactly like a "continue" operation of a visual debugger. It causes the program execution to continue until the next break point or the program exits.
The best thing to read is the GDB users' manual.
There are a few gdb guis for windows in this question windows version of the GDB frontend DDD
Although DDD hasn't been ported