Moving from dbx to gdb:
I would like to permanently suppress the information gdb prints out on my terminal while attaching to a running process in its entirety. Does anyone know how to do that? Thank you for any help.
Sample (64-bit CentOS 6.6) session:
gdb -p 12345
Attaching to process 12345
Reading symbols from /some/path/to/my/ELF executable...done.
Reading symbols from /some/other/path/to/my/library.so...done.
Loaded symbols for /some/other/path/to/my/library.so
[New LWP 12345]
[New LWP 12345]
[New LWP 12345]
[New LWP 12345]
[Thread debugging using libthread_db enabled]
0x000000338a6aca3d in nanosleep () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install ...
In reality there are multiple screens of the above 'Reading' and 'Loading' entries which I am suppressing manually for sanity sake. There are also 4 100-character long lines of complaints about "Missing separate debuginfo" which I am also manually suppressing for the post.
Do not want to see any of it. All I want is this:
gbd -p 12345
in nanosleep () from /lib64/libc.so.6
which is somewhat useless - where are the current file and function names plus the line number and thread id? But I am willing to overlook this. More interested in suppressing the output for now (not eliciting it).
Is this easily achievable with gdb? An entry in .gdbinit or some such? Thanks again.
You may suppress the "Missing separate debuginfos" complaints with the command set build-id-verbose 0 (this setting does not appear to be well documented).
If these warnings appear when you start a program with gdb, it may be useful to include that line in your .gdbinit file.
As far as I know there is no way to disable these.
Some extra messages are printed if you have set print inferior-events on. So, make sure it is off. But, it probably is for you, as that is the default.
You can make some specific commands quiet by writing your own wrapper using define and having it redirect output to /dev/null.
I think giving users more control over the output would be a reasonable feature request for gdb.
Resolved.
Though I could not find a way to silence the "Missing separate debuginfos" complaints via redirecting them to /dev/null I have managed to get rid of them by doing what they suggested:
become root.
vi /etc/yum.repos.d/CentOS-Debuginfo.repo
change "enabled=0" to "enabled=1"
save and exit vi.
yum install yum-utils
debuginfo-install glibc
debuginfo-install keyutils-libs
debuginfo-install krb5-libs
debuginfo-install libgcc
debuginfo-install libuuid
debuginfo-install openssl
gdb sessions look much cleaner now. Thanks.
Related
I am trying to analyze segfault on a core file on linux. I am not sure if the following behavior is correct, thus i deliberately caused a segfault using
#include <signal.h>
int main() {
raise(SIGSEGV);
}
the binary is build with debug info i.e.
file mainTestFile
mainTestFile: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, with debug_info, not stripped
notice how it does say "with debug_info, not stripped" at the end
when i execute the binary i get a core file generated which is called core-mainTestFile.20474
(In order to generate the core file i hat to set my ulimit to unlimited i.e.
ulimit -c unlimited
)
if i run only the binary under GDB and do backtrace "bt" then i get the segfault and i get all names of the functions involved
printed nicely i.e. notice how the gdb says when starting "reading symbols from ./mainTestFile...done."
gdb ./mainTestFile
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
....
reading symbols from ./mainTestFile...done.
(gdb) run
Starting program: /src/exe/mainTestFile
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x0000000000402dad in main (argc=1, argv=0x7fffffffda38) at /src/exe/main.cpp:53
(gdb)
however if i try to anaylise only the core file with gdb like that
gdb -c core-mainTestFile.20474
then i get only question marks
the when i execute "bt" then i do not see the names of the methods, instead i get question marks
(gdb) bt
#0 0x00007f34d8842e97 in ?? ()
#1 0x0000000000000000 in ?? ()
they only workaround i found is to supply the binary directly at the command line then it all gets printed nicely.
even if i try to tell GDB to use the symbols file and point that to the binary file which does have the symbols
i.e.
symbol-file /src/exe/mainTestFile
then GDB says
Reading symbols from /src/exe/mainTestFile...done
and when i execute bt i see the question marks again? Why is that. Is GDB not able to get the symbols out of the binary?
it only works if supply the binary directly on the command like like:
gdb /src/exe/mainTestFile -c core-mainTestFile.20474
my question is should the GDB be able to read symbols of the binary when directly supplying him the binary over the "symbol-file" command or not. Why is this working when supping him directly the binary over the command line, what is the difference?
should the GDB be able to read symbols of the binary when directly supplying him the binary over the "symbol-file" command or not.
In theory, using symbol-file and core-file commands in either order in GDB should be equivalent.
But there is a bug: symbol-file followed by core-file works, and the opposite order doesn't.
Since generally the end-user can always rearrange his commands into the order that works, this has never propagated to the top of any GDB developer's queue of things to fix.
Related bug (but not an exact duplicate).
I have an embedded ARM application which is bundled with all the so-libraries stripped, including the libpthread.so. Sometimes the application gets stuck in some part of code and I want to be able to attach to it with gdb and see what's going on. The problem is that gdb refuses to load the needed threading support library, with the following messages:
Trying host libthread_db library: /home/me/debug_libs/libthread_db.so.1.
td_ta_new failed: application not linked with libthread
thread_db_load_search returning 0
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
Because of this I cannot debug the application, e.g. I cannot see current call stacks for all threads.
After some investigation I suspect that the td_ta_new failing with the application not linked with libthread is caused by the stripped version of libpthread, which lacks the nptl_version symbol. Is there any way to bypass the error?
The gdb is compiled for ARM and being run on the device itself. I have unstripped versions of the libraries, but the application is already running with the stripped libraries.
Is there any way to bypass the error?
A few ways that come to mind:
Use add-symbol-file to override the stripped libpthread.so.0 with un-stripped one:
(gdb) info shared libpthread.so
# shows the path and memory address where stripped libpthread.so.0 is loaded
(gdb) add-symbol-file /path/to/unstripped/libpthread.so.0 $address
# should override with new symbols, and attempt to re-load libthread_db.so.1
Run gdb -ex 'set sysroot /path/to/unstripped' ... where /path/to/unstripped is the path that mirrors installed tree (that is, if you are using /lib/libpthread.so.0, there should be /path/to/unstripped/lib/libpthread.so.0.
I have not tested this, but I believe it should work.
You could comment out the version check in GDB and rebuild it.
I'm using gcc 4.9.2 & gdb 7.2 in Solaris 10 on sparc. The following was tested after compiling/linking with -g, -ggdb, and -ggdb3.
When I attach to a process:
~ gdb
/snip/
(gdb) attach pid_goes_here
... it is not loading symbolic information. I started with netbeans which starts gdb without specifying the executable name until after the attach occurs, but I've eliminated netbeans as the cause.
I can force it to load the symbol table under netbeans if I do one of the following:
Attach to the process, then in the debugger console do one of the following:
(gdb) detach
(gdb) file /path/to/file
(gdb) attach the_pid_goes_here
or
(gdb) file /path/to/file
(gdb) sharedlibrary .
I want to know if there's a more automatic way I can force this behavior. So far googling has turned up zilch.
I want to know if there's a more automatic way I can force this behavior.
It looks like a bug.
Are you sure that the main executable symbols are loaded? This bug says that attach pid without giving the binary doesn't work on Solaris at all.
In any case, it's supposed to work automatically, so your best bet to make it work better is probably to file a bug, and wait for it to be fixed (or send a patch to fix it yourself :-)
I have a program and I am trying to debug it using gdb. Inside the program I have methods that require the user to enter an input using stdin. How can I enter this input when I am in gdb? So that I can trace how my methods work?
$ cat >foo <<EOF
something
EOF
$ gdb -quiet /bin/cat
Reading symbols from /bin/cat...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install coreutils-8.12-7.fc16.x86_64
(gdb) run <foo
Starting program: /bin/cat <foo
something
[Inferior 1 (process 22436) exited normally]
(gdb)
You can also run your program first, then attach GDB to it:
gdb --pid $(pgrep your_program)
This way you will be able to run your program interactively in a separate terminal.
I just went through something like this yesterday and recursed through a bunch of "help" commands in gdb because I couldn't find exactly what I needed on the Internet.
I used set variable *your_variable* = *your desired input* after I had started gdb and began running my code. Worked like a charm.
I know this is late, but maybe it'll help someone else.
I'm doing an OS class that's based on xv6 and I wrote a program that needs to run on it.
I know that I can debug kernel code with make qemu-gdb but I'm not sure how to debug my own user program.
Lets say I want to debug cat, how would I go about doing that?
Thanks
P.S. isn't there an xv6 tag? should this question even go here?
From the xv6 top-level dir:
Run the emulator in debug mode (assuming no X11): make qemu-nox-gdb
In other terminal just run the debugger loading the kernel symbols with:
gdb kernel This is important, otherwise the debugger will be confused between kernel and and user program symbols, for example main()
From the gdb interface run: (gdb) target remote localhost:26000
where 26000 is the TCP port that the step #1 report at the end (this might change).
Load the user exec with (gdb)file user_program
Place a breakpoint (gdb) break main and continue with (gdb) continue
etc...
file cat, break main, continue
semi reference running and debugging xv6