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.
Related
I invoked gdb to attach a current running process with this command sudo gdb binary PID. After that I set breakpoints and typed continue in gdb. Then I sent a request to this process to hit the breakpoint. After that, when I type command list, it only shows one line instead of multiple lines as expected, and it only shows line number instead of contents. And may I ask what does the output of command n mean? On the internet some docs mentioned it means the next line to be executed. But from the output itself, it doesn't make too much sense to me(after two n commands the last l command shows 169 instead of 172 or 174). Can anyone help answer above two questions? Really appreciate it.
(gdb) l
164 in CBFEMultiSectionResponseModule.cc
(gdb) n
172 in CBFEMultiSectionResponseModule.cc
(gdb) l
167 in CBFEMultiSectionResponseModule.cc
(gdb) n
174 in CBFEMultiSectionResponseModule.cc
(gdb) l
169 in CBFEMultiSectionResponseModule.cc
The build command line for this source file is like this:
/usr/bin/g++ -c -fPIC -DMODULEADAPTER_BUILTIN_VERSION=\"2.36.375.10894.aff30c2\" -DLINUX -D_GNU_SOURCE -D_THREAD_SAFE -DUSE_STD_YUTSTRING -I../api -I. -I/home/y/include/ydisc \
-I/home/y/include/avro -I../.. -I../../.. -I../../../external_interfaces -I../../../sg_interfaces -I/home/y/include64 -I/home/y/include
\-fPIC -g -O2 -Wall -Werror -Wno-invalid-offsetof -fno-strict-aliasing -pipe -MD -MP
\-DYAHOO_PLATFORM_MAJOR=6 -DYAHOO_PLATFORM_MINOR=10 CBFEMultiSectionResponseModule.cc -o x86_64-linux-gcc/CBFEMultiSectionResponseModule.o
This is the filesystem type:
-bash-4.1$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 246G 97G 137G 42% /
tmpfs tmpfs 12G 30M 12G 1% /dev/shm
Below is the output of info source:
(gdb) info source
Current source file is CBFEMultiSectionResponseModule.cc
Compilation directory is /home/myusername/ufe/modules/multisectionresponse/impl
Source language is c++.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
Below is the output of shell cat:
(gdb) shell cat /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc
cat: /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc: No such file or directory
when I type command list, it only shows one line instead of multiple lines as expected, and it only shows line number instead of contents
This is most likely happening because GDB has no access to the source. The sudo is the key here. Your source likely resides on a filesystem that doesn't allow root access, such as NFS.
it doesn't make too much sense to me(after two n commands the last l command shows 169 instead of 172 or 174).
You are debugging optimized code. See e.g. this answer.
Update:
The path to source is correct in the compilation environment. However, the runtime environment is different than the compilation env ..
Well, why didn't you tell us that?
My answer is correct: GDB doesn't list source because source is inaccessible (it's just inaccessible for a different reason from what I guessed).
If you want GDB list command to work in the runtime environment, then you must make the source available (though not necessarily in the same location; use dir command to point GDB to the location where sources are available).
Update 2:
. I used to think GDB has some magic ways to get the source code from the binary.
The binary does not contain sources (that would make significantly larger). Instead, it contains references to the source locations.
In particular, the compiler encodes into the binary for each translation unit (each .cpp file):
Compilation directory
Name of the source file(s) (there could be more than one due to #includes).
A mapping from program counter to file/line that the particular chunk of assembly was generated for.
(There is additional info describing variable locations, types, etc. But these are irrelevant to the list command.)
GDB decodes above into, locates the source file(s), and allows you to set breakpoints by file/line, lists the source when you hit the breakpoint, etc.
A program compiled with arm-linux-gnueabi-gcc -g3 main.c .
$ gdb a.out
$ l
$ main.c: No such file or directory.
It is unable to display program lines with line number. let me know If i am missing something ?
However I am able to run program , with run command even backtrace I am able to get.
My issue is same as gdb can not load source file?
but , GDB version 7.8.
GDB needs source code to be present on same machine as in where binary been run.
mine was cross compilation , I was running program on different host . That's why I had that issue.
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!
I created a Hello World example in C++ and tried to debug it with lldb from the terminal on Mac OSX.
> lldb a.out
Current executable set to 'a.out' (x86_64).
I can set breakpoints on names (eg. 'main'), but not on line numbers. If I try
breakpoint set --file test.c --line 5
or
b test.c:5
I get
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
The file 'test.c' is located in the current folder. What goes wrong?
Acording to Dwarf Debugging Information Format, the line number, file location information are stored in the Dwarf format. Such information is what GDB used to set line number as a breakpoint.
Usually, the Dwarf format information is generated by compiler, such as GCC with the -g options. Please try with -g options to see whether it works.
Meanwhile, there also some other debug helpful options in GCC which might be more helpful to you, such as -g3, compiler will generate more detail information for debug, such as macros.
I'm developing on an ARM9E processor running Linux. Sometimes my application crashes with the following message :
[ 142.410000] Alignment trap: rtspserverd (996) PC=0x4034f61c
Instr=0xe591300c Address=0x0000000d FSR 0x001
How can I translate the PC address to actual source code? In other words, how can I make sense out of this message?
With objdump. Dump your executable, then search for 4034f61c:.
The -x, --disassemble, and -l options are particularly useful.
You can turn on listings in the compiler and tell the linker to produce a map file. The map file will give you the meaning of the absolute addresses up to the function where the problem occurs, while the listing will help you pinpoint the exact location of the exception within the function.
For example in gcc you can do
gcc -Wa,-a,-ad -c foo.c > foo.lst
to produce a listing in the file foo.lst.
-Wa, sends the following options to the assembler (gas).
-a tells gas to produce a listing on standard output.
-ad tells gas to omit debug directives, which would otherwise add a lot of clutter.
The option for the GNU linker to produce a map file is -M or --print-map. If you link with gcc you need to pass the option to the linker with an option starting with -Wl,, for example -Wl,-M.
Alternatively you could also run your application in the debugger (e.g. gdb) and look at the stack dump after the crash with the bt command.