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.
Related
I am currently self-studying 2020 MIT 6.S081: Operating System Engineering https://pdos.csail.mit.edu/6.828/2020/schedule.html. I have followed all the steps for MAC OS to set up the environment correctly.
When I launched gdb and qemu together, I was able to break points normally when debugging the kernel executable.
However, when I attempted to do the same thing for the user executables, I was unable to break any points with the error:
Cannot access memory at address 0x...
It turned out I can set break points for some particular lines, but when I hit continue, another error has shown in the screenshot above.
Any way to get around this? Thank you!
I'm also self-studying 6.S081 and have had the same issue. I solved this just now so try this.
In Makefile, add -gdwarf-2 option to CFLAGS variable:
CFLAGS = -Wall -Werror -O -fno-omit-frame-pointer -ggdb -gdwarf-2
In my Makefile it's on line 94, and I didn't change other options.
I find this solution from here:
http://staff.ustc.edu.cn/~bjhua/courses/ats/2014/hw/hw-interface.html (search 'error reading variable' in the page)
https://www.reddit.com/r/RISCV/comments/plgwyk/comment/hcalnf1/?utm_source=share&utm_medium=web2x&context=3
and one more thing: If you successfully solve the problem with this but fail to watch variables in gdb, try chainging -O option for CFLAGS to -O0. It would prevent your code from being optimized (ref). (For me, this doesn't work. my code start to stuck frequently after changing this option so I just quit watching variables)
You can check out whether your gdb has warned you can't use file .gdbinit to start gdb? If not, you can simply add a line to .gdbinit: set riscv use-compressed-breakpoints yes,like this:
set confirm off
set architecture riscv:rv64
target remote 127.0.0.1:26000
symbol-file kernel/kernel
set disassemble-next-line auto
set riscv use-compressed-breakpoints yes
then use riscv64-unknown-elf-gdb to start gdb.You will see it work well.
But if you have the warning, then you should use
riscv64-unknown-elf-gdb -iex 'add-auto-load-safe-path .' to start gdb additionally.
Is nacl-gdb only for *.nexe and not *.pexe files? im following the guide at https://developers.google.com/native-client/devguide/devcycle/debugging#gdb
./$NACL_SDK_ROOT/toolchain/mac_x86_newlib/bin/x86_64-nacl-gdb
...
This GDB was configured as "--host=i386-apple-darwin10.8.0 --target=x86_64-nacl".
...
(gdb) nacl-manifest code.nmf
(gdb) nacl-irt pnacl/Release/code.pexe
`pnacl/Release/code.pexe': can't read symbols: File format not recognized.
The .pexe is not the final executable, and nacl-gdb does not understand its format. It's a target-independent "intermediate format" file that has to be translated by the browser to a native module before it can be executed and/or debugged.
You can debug .nexes produced by the PNaCl toolchain, by compiling all the way to a .nexe with debug information and then debugging that. In other words, just as you debug a .nexe produced by the gcc toolchains.
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.
In c or c++ While debugging a core dump,i.e., if we are left with a coredump file and try to debug using that core file is there a way we can see the last few lines of code before the dump occured.the stack trace only shows the function call.
for eg:during debugging a running process in dbx or gdb list command
list Display lines of a source file
will give the part of the code currently under execution.in the same way do we have the option while looking into a core dump?
i am working on solaris mdb
The list command in gdb should provide details of source code line numbers and the corresponding source listing from a core file if:
The executable was compiled with debug symbols enabled (eg. -g in gcc and g++)
A non-stripped version of the executable is available (ie. has not had the debug information removed by running strip)
The debugger is able to find the relevant source files
The debugger should still be able to provide file and line numbers even if it is unable to find the source files as the line number information forms a part of the debug symbols. This information should be available through the bt (backtrace) command, as well as the info symbol command.
Note that even if the core file was generated from a stripped executable, as long as you have access to a non-stripped version you can load that in gdb as well as specifying the core file.
Take a look at chapter 13 and 15 of the gdb manual to assist in giving gdb access to your source files.
If you compiled with -g option you can display source lines. In dbx you can use use command to set dbx source directories.
You can use list (l) command to display source lines.
See help command to learn how to use dbx and gdb commands.
If you have set your source path properly using use command in dbx or started it with -I option, then there's hardly any difference between debugging a core dump and a normal process when it comes to reading source lines.
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.