first of all, the optimization level is -O0, and include -ggdb3 flag
when I use gdb to debug, the tracepoint is not consistent with the line number which I use "list" to get, it always over a few lines; the cpp has over 10000 lines, whether is it because the file is so large that make gdb be wrong in line number.
for example, the tracepoint of gdb is 1005 line, but actually it is only on 1000 line.
Here's a previous question that largely answers yours.
In addition, do you include the -g to include debug information.
I find the reason, the cpp file is upload from windows, this format of file is DOS, every line has a "line feed", so the gdb get wrong info.
change the format of file from dos to uinx is OK!
Related
I am maintaining hardware monitor program, which will be executed in 16-bit MS-DOS.
I use dosbox with TurboC(tcc.exe) as build environment
While the dos command line can't accept command exceed 128 characters (Ref) ,
but I have a long argument list like this:
tcc.exe -ID:\tc\include -LD:\tc\lib -o MyProgram.exe MyProgram.cpp A.obj B.obj C.obj .........
So I can't build the code successfully. Anyone has idea to overcome this situation? Thanks.
Check your compiler documentation. Many compilers allow parameters to be placed into a text file and the name of the text file given as a command line parameter.
For example, if "compiler_options.txt" hold commands than the following may be how to pass the file:
tcc.exe #compiler_options.txt
Read the documentation to find out if the capability is supported and the correct command line syntax.
Have you tried setting the value to it's maximum in the CONFIG.SYS file:
shell=c:\windows\command.com /u:250 /p
I have met a freaky problem during my internship. My work is to code with VTK in C++ and I worked on OSX 10.8.3.
When I want to debug my program, I ran the gdb and use instruction "file" to load my program, then I used "list" to show the source code to make a breakpoint by line number. Here goes the problem: this freaky gdb showed the source code of a VTK header file which I even hadn't included in my source code!
My program's name is read
I have tried to use gdb read then break read:15 to set a breakpoint but the gdb displayed "no source file named read" that is ridiculous!
I have noticed that gdb works well in my ubuntu 12.04 and when I use file read in linux's gdb, it just displayed
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
but in my OSX 10.8.3's freaky gdb it displayed
Reading symbols for shared libraries ......... done
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
I think that is the reason and I tried to change compiler to solve problem by install gcc4.8 in macport but cmake seems only accept the apple's gcc.
but the gdb displayed "no source file named read" that is ridiculous!
That is not rigiculous at all: you very likely don't have a source file called read. What you do have is probably called read.cc, or read.cpp, so try break read.cc:15.
That is my mistake: I didn't set the build tag to "debug" in ccmake, so the compiler didn't write the information into 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.
GDB is not showing me the line source after next/stop , and displays only line number and source file , like this :
(gdb) n
7 in test/test.c
whereas I expect it to display the current line , like this :
(gdb) next
17 char * good_message = "Hello, world.";
any settings in .gdbinit that might help me do this ?
whereas I expect it to display the current line , like this
On many platforms, such as ELF, the compiler records both the path to the source (test/test.c in your case), and the compilation directory, allowing GDB to display source regardless of which directory you invoke it in.
But many platforms are less flexible, and don't have a place to record compilation directory. On such platforms (e.g. AIX), you must either start GDB in the compilation directory, or tell it where to look for sources with directory command.
Probably my answer may not be a perfect solution but the way you compile your source program matters. For example in my case if you do g++ fib.cpp -o fib and then try to run gdb fib it won't print the source code with list. Using debug flag g++ -g fib.cpp -o fib and then running with gdb solved my problem.
I'm debugging a nasty problem where #includeing a file(not anything I wrote, for the record) causes a crash in my program. This means, I have working and broken, with only one C(++) include statement changed. Some of the libraries I'm using don't have debugging information.
What I would like to do is get GDB to output every line of C++ executed for the program run, and x86 instructions where not available to a textfile in such a format that I can diff the two outputs and hopefully figure out what went wrong.
Is this easily possible in GDB?
You can check the difference between the pre-processed output in each version. For example:
gcc -dD -E a.cc -o a.pre
gcc -dD -E b.cc -o b.pre
diff -u a.pre b.pre
You can experiment with different "-d" settings to make that more verbose/concise. Maybe something in the difference of listings will be obvious. It's usually something like a struct which changes size depending on include files.
Failing that, if you really want to mess with per-instruction or line traces, you could probably use valgrind and see where the paths diverge, but I think you may be in for a world of pain. In fact you'll probably find valgrind finds your bug and then 100 you didn't know about :) I expect the problem is just a struct or other data size difference, and you won't need to bother.
You could get gdb to automate line tracing. It would be quite painful. Basically you'd need to script it to run "n" (next line) repeatedly until a crash, then check the logs. If you can script "b main", then "run", then infinite "n" that would do it. There's probably a built-in command to do it but I'm not aware of it.
I don't think GDB can do this; maybe a profile will help, though? Are you compiling with gcc? Look at the -p and -pf commands, I think those might be useful.
The disassemble command at the gdb prompt will disassemble the current function you are stopped in, but I don't think outputting the entire execution path is feasible.
What library are you including? If it is open source, you can recompile it with debugging symbols enabled. Also, if you're using Linux, most distributions have -dbg versions of packages for common libraries.