How does gdb print structs? From the "GDB Internals" document referenced by zengr at how does gdb work? it looks like GDB loads symbols in from one or more symbol tables using the BFD library. If this is the case, how does gdb know how to print structs? The name of the gdb source code file(s) containing the printing algorithm would be greatly appreciated (I tried to find it myself but couldn't).
GDB does use the BFD library, but it has much more code to handle symbols than what BFD provides. You are looking for val_print() in valprint.c
Related
I need to get the list of shared libraries used by an app in runtime. Most of them can be listed by ldd, but some can be seen only with gdb -p <pid> and by running the gdb command info sharedlib.
It would really help, if I could learn in some way: for a chosen library (in the list, output by info sharedlib), which library (of the same list) had caused to load it. Is there any way to learn it in gdb or in some other way? Because sometimes, I see a loaded library in the list and cannot get why it is there and which (probably, previously loaded in memory) library loaded it.
UPDATE:
I attach a screen shot of gdb showing the info that I need. I used breakpoint on dlopen, as it was suggested in comments and in the answer. The command x/s $rdi prints out the first argument of dlopen, as by Linux System V ABI, i.e. it prints the name if the library, about which I want to learn who loaded it (libdebuginfod.so.1). I put it here just for those who are curious. In my case, it can be seen, that the libdebuginfod.so.1 was loaded by libdw.so.1 (as shown by bt command).
Is there any way to learn it in gdb or in some other way?
There are a few ways.
You can run the program with env LD_DEBUG=files /path/to/exe.
This will produce output similar to:
LD_DEBUG=files /bin/date
76042:
76042: file=libc.so.6 [0]; needed by /bin/date [0]
It is the needed by part that you most care about.
You could also use GDB and use set set stop-on-solib-events 1. This will produce output similar to:
Stopped due to shared library event:
Inferior loaded /lib/x86_64-linux-gnu/libc.so.6
At that point, you could execute where command and observe which dlopen() call caused the new library to be loaded.
You could also set a breakpoint on dlopen() and do the same.
The stop-on-solib-events may be better if your executable repeatedly dlopen()s the same library -- the library set will not change when you dlopen() the same library again, and you'll stop when you don't care to stop. Setting stop-on-solib-events avoids such unnecessary stops.
I'm trying to read the backtrace of my OCaml program inside GDB. The output looks like the following:
(gdb) bt
#0 0x0000000100535ac6 in .L207 ()
#1 0x0000000100535acb in .L207 ()
#2 0x0000000100535acb in .L207 ()
...
How can I interpret this kind of output?
EDIT:
I've enabled debug info by using ./configure --enable-debug (I'm using oasis).
I'm using GDB 7.9.1 on OS X 10.10
I'm using OCaml 4.02.2
EDIT 2: the output seems to be correct with the Linux version of GDB. Does anyone know why there is such a difference between the OS X and Linux versions?
Check what C compiler and assembler is used. Mac OS probably uses clang and it may not generate full debug info for gdb. In that case using lldb may be more fruitful.
Did you compile with -g? I typically get stuff like #3 0x0000000000401f49 in caml_program (). There's also export OCAMLRUNPARAM=b, gives stacktraces when your program crashes.
(You might want to post a code snippet and the compile commands.)
You may also find http://www.ocamlpro.com/blog/2012/08/20/ocamlpro-and-4.00.0.html and http://oud.ocaml.org/2012/slides/oud2012-paper5-slides.pdf handy.
Have you looked into using ocamldebug instead, or do you have to debug on the machine end?
If you want to understand what your code is doing on the CPU/Register/Assembly/Bitfiddling-witchcraft end then it might be more informative to read Jane Street's blog post writing performance sensitive ocaml code.
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.
I've configure all CONFIG_DEBUG_ related options to y,but when I try to debug the kernel,it says no debug symbols found:
gdb /usr/src/linux-2.6.32.9/vmlinux /proc/kcore
Reading symbols from /usr/src/linux-2.6.32.9/vmlinux...(no debugging symbols found)...done.
Why?
Here is my best guess so far: I don't know, and it doesn't matter.
I don't know why GDB is printing the message "(no debugging symbols found)". I've actually seen this when building my own kernels. I configure a kernel to use debug symbols, but GDB still prints this message when it looks at the kernel image. I never bothered to look into it, because my image can still be debugged fine. Despite the message, GDB can still disassemble functions, add breakpoints, look up symbols, and single-step through functions. I never noticed a lack of debugging functionality. I'm guessing that the same thing is happening to you.
Edit: Based on the your comments to the question, it looks like you were searching for the wrong symbol with your debugger. System call handlers start with a prefix of sys_, but you can't tell from looking at the code. The macro SYSCALL_DEFINE4(ptrace, ...) just ends up declaring the function as asmlinkage long sys_ptrace(...), although it does some other crazy stuff if you have ftrace enabled.
make menuconfig->kernel hacking->[]Kernel debugging->[]Compile the kernel with debug info(CONFIG_DEBUG_INFO)
It's also possible when you package your vmlinuz image, the debug symbols were stripped (when using make-kpkg to build deb package for linux kernel). So you have to use the built vmlinux file under your linux source tree to have those debug symbols.
Add -g to the CFLAGS variable in the kernel Makefile
I might be wrong, but I thought you would have to install the debuginfo package for your kernel to get symbols
Is there any x86 disassembler framework that can be used to analyze code from a specific address in a program, as in:
info = disassemble( startAddress , stopAddress)
It should show every instruction and its operands and any other info that is good for analysis but it should have also fast mode where it isn't so important to obtain that much info for each instruction, but only for some of them that can be specified.
Is GNU binutils not good enough? Here's how to do that with the objdump utility:
# Disassemble from virtual addresses 0x80000000 to 80000100
objdump -d program --start-address=0x80000000 --stop-address=0x80000100
Google's protobuf uses libdisasm for that matter. Sad thing is that (judging from source code) it only supports ia32 and x86 and homepage states that "it is x86 specific and will not be expanded to include other CPU architectures". But since you didn't mention other archs, this library may be sufficient.
The cross-platform InstructionAPI suits this purpose, it will analyze the code and can print out the disassembly or provide a machine-independent view of the instructions for you to query. InstructionAPI is a shared library that you would link your code against.
http://www.paradyn.org/html/manuals.html
I would debug to the start point and look at the disassembly output of the debugger. A more brutal method is to disassemble it all and search for the function name in the disassembly file. objconv can do this, but it is slow on very big files.
Try BeaEngine