Can't disable pagination in gdb - debugging

I can't seem to disable pagination in gdb. I've read all of the various answers suggesting to add set pagination off or set height 0 or set height unlimited to my ~/.gdbinit file, and I've tried all of them, but gdb seems to be ignoring them all. When I start gdb, it is clearly reading the ~/.gdbinit file, as I am able to set the auto-load safe-path, however every time I start, I have to hit enter again to start gdb, which is intensely frustrating. It's as if it's just completely ignoring the pagination off command. I've also tried adding these commands to the system-wide gdbinit (in /etc/gdb/gdbinit), but this didn't work either.
For what it's worth, I'm running Xubuntu 18.04 with GDB version (GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git). The .gdbinit file currently reads:
set auto-load safe-path /
#set height 0
#set height unlimited
set pagination off
EDIT: To clarify, for various reasons I have to have my terminal fairly short (~13 lines or so). When I start GDB, I am greeted by the following:
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
---Type <return> to continue, or q <return> to quit---
After hitting <return>, the rest of the intro message is displayed, and I can start using GDB. This is not desirable behaviour for me, and I would prefer if this pagination did not occur.

After hitting , the rest of the intro message is displayed, and I can start using GDB.
Reproduced.
The issue is that GDB prints the copyright banner before it reads ~/.gdbinit. Since the copyright doesn't fit, and since the .gdbinit hasn't yet been read, you get the pagination prompt.
Solution is trivial: suppress the copyright banner, like so: gdb -q ....

Related

No debugging symbols found in ./d8

run v8's d8 command, prompt (No debugging symbols found in ./d8). after executing the command, exit the program.
here is a hint of the code.
➜ x64.debug git:(e47af00448) ✗ gdb ./d8 // this
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.6.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./d8...
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/async-hooks-wrapper.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-console.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-js.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-platforms.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-posix.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-test.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8.o': file time stamp mismatch.
(No debugging symbols found in ./d8)
expect
can be used normally.
d8 produced using the gm x64.release command
Release builds don't have debugging information. Try gm x64.debug.
That said, the error message you posted does mention .../out/x64.debug/obj/..., so it's not clear how you actually built. Are you maybe trying to force one build's debugging information into another build's GDB session? That isn't going to work.
file time stamp mismatch sounds like recompiling might fix it, have you tried that?
Also, the usual workflow is to remain in the main checkout directory, and invoke d8 as gdb -args out/x64.debug/d8 .... If that was the problem, the error would likely look different though.
Another shot in the dark: try LLDB, which may work better on MacOS.

Cross platform: Debugging using WSL under Windows fails when using shared dynamic libraries using Visual Studio 2019

I have a project consisting of a few libraries which is cross platform and runs and debugs just fine if all the source code is in one Visual Studio 2019 project. However, having the libraries in separate projects and I cannot debug from within the IDE at all. However, the executable will run perfectly ok from the command line in my WSL installation and on other Linux boxes. I have tried various things such as setting my LD_LIBRARY_PATH as one of the projects is a shared dynamic library, but nothing so far seems to work. Anyone have any ideas on this ? Thanks
Update: if I manually copy the dynamic library e.g.
cp libWSI.so /usr/lib/x86_64-linux-gnu/libWSI.so
debugging works. But this is not ideal.
The output I get from the Debugger is this:
=thread-group-added,id="i1"
GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Inferior 1 (process 1438) exited with code 0177]
The thread 'WSITests.out' (0x59e) has exited with code 0 (0x0).
The program '' has exited with code 177 (0xb1).
My debugger won`t start even with the libs in the same folder when using dynamic linking. I have found a workaround here: https://github.com/Microsoft/VSLinux/issues/257
You have to make a script, let`s say "debug.sh", where you add the paths to your lib folders and run the debugger with --interpreter=mi argument. I suspect this gdb argument does the magic in this case.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/c/Users/mircea.goga/source/repos/TestCoreCLRLinux/Out/
/usr/bin/gdb --interpreter=mi
In Visual Studio, set the path to this file to "Remote GDB Path" in "Debugging" section.
image

GDB 7.6 STL pretty print with gcc-4.8 and mac os 10.9

I'm struggling to get the pretty prints as described here in gdb working on my mac. I downloaded the latest gdb through macports and using gcc-4.8.
I loaded the ~/.gdbinit file and the printers are registered, but whenever I call
print myVector it gives me the raw output.
Any suggestions what I could do? Thanks a lot guys!
To have pretty printer with libc++ (new library used in Clang++/LLVM) use this new pretty printer:
https://github.com/koutheir/libcxx-pretty-printers
The .gdbinit is almost the same (see sample)
I've just tried with Eclipse Luna on OS X 10.10 and it works.
Any suggestions what I could do?
You can try to register pretty printers directly from gdb command line, bypassing .gdbinit file to narrow down the problem:
ks#ks-comp:~$ gdb -n
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python
>import sys
>sys.path.insert(0, '/home/ks/stlPrettyPrinter')
>from libstdcxx.v6.printers import register_libstdcxx_printers
>register_libstdcxx_printers (None)
>end
(gdb)
Note, that I've checked out pretty printers in /home/ks/stlPrettyPrinter folder:
ks#ks-comp:~$ ls -a /home/ks/stlPrettyPrinter
. .. hook.in index.html libstdcxx Makefile.am Makefile.in patch.txt .svn
ks#ks-comp:~$
If you're using the STL implementation in libc++ (the default with clang), GDB won't know how to pretty print the STL containers
Switch to using GNU libstdc++, and STL pretty printing in gdb should work.
STL pretty printers are implemented as Python programs that know about the implementation details of the STL containers and are maintained along with the STL implementations.
libc++ does not ship STL pretty printers that confirm to the GDB Python pretty printer API
Since you got your gcc-4.8 from MacPorts and MacPorts: Using the Right Compiler claims that gcc-* defaults to libstdc++ you should just avoid passing the -stdlib= option when using gcc.

Backtrace for osx core dump using lldb

My kernel extension crash a several times so I want to get the correct backtrace (with function names) from the crash
Accroding to the article https://developer.apple.com/library/mac/technotes/tn2004/tn2118.html
I wanted to use gdb for this, but it seems that GDB does not understand the dump
dhcp80-241:KernelDebugKit gburanov$ sudo gdb -c /PanicDumps/core-xnu-2050.48.12-10.41.20.195-39882f44
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".
Core file contained no thread-specific data
(gdb)
I heard that it is not possible by gdb, but lldb does not work as well
dhcp80-241:KernelDebugKit gburanov$ lldb
(lldb) target create -d -c /PanicDumps/core-xnu-2050.48.12-10.41.18.191-2c2bf92f /Volumes/KernelDebugKit/mach_kernel
Loading kernel debugging from /Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/mach_kernel.py
LLDB version LLDB-179.5
settings set target.process.python-os-plugin-path "/Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
command script import "/Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
xnu debug macros loaded successfully. Run showlldbtypesummaries to enable type summaries.
error: Unable to find process plug-in for core file '/PanicDumps/core-xnu-2050.48.12-10.41.18.191-2c2bf92f'
(lldb)
What is the correct way to work with core dumps?
That looks like an lldb from Xcode 4.6 - I can't remember the state of core file support that version had -- and the kernel debug commands provided with the kenel dSYM aren't going to work with that lldb. You'll need to install Xcode 5.1 to get this to work.
The fact that gdb said it couldn't find a register context in the core file may indicate that you have a corrupt/truncated core file. The lldb in Xcode 5.1 will be a better check on that.

How Should I Debug Samba with GDB

I'm not good at English, and I'm sorry about that.
Now, There is a question about when I debug samba with GDB.
# gdb /usr/local/samba/sbin/smbd
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /usr/local/samba/sbin/smbd
Program exited normally.
(gdb) info program
The program being debugged is not being run.
So, How should I debug samba with GDB?
ps: Version of Samba 3.0.5 I install samba from source code.
you may use sudo ./smbd -i to start smbd and see what's wrong with it.
in my case:
smbd try to find smb.conf in /usr/local/samba/etc/smb.conf and there isn't one, so exit.
i copy /etc/samba/smb.conf to the disired path , then everything ok.
hope this can help you.
Download samba source code from http://www.samba.org and compile it (without source code, it will be impossible to do symbolic debugging).
Stop or kill any other samba instances.
Start samba under gdb:
gdb <path/to/compiled/smbd>
Specify smbd parameters:
set args -i -M single
Parameters -i -M single force smbd to start as single process, do not daemonize and print all messages and errors to stdout/stderr.
Now, you can set breakpoints and trace your source code as you normally would with any other program.
Note: instead of using gdb, you might find more convenient to use gdb-tui (gdb text user interface), or use other debuggers like ddd.

Resources