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.
Related
system:
mac osx catalina (10.15.5)
gfortran 9.3.0 (from homebrew)
gdb 9.2 (from homebrew)
went through and followed these instructions:
https://sourceware.org/gdb/wiki/PermissionsDarwin
trying to debug on this program just to learn:
! test.f90
program main
integer :: val
val = 1
print *, val
val = 2
print *, val
end program main
compile with:
gfortran test.f90 -Og -g -o test
then at the terminal
~/Coding/gdb
> ./test
1
2
~/Coding/gdb $
> gdb test
GNU gdb (GDB) 9.2
Copyright (C) 2020 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-darwin19.4.0".
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"...
Reading symbols from test...
Reading symbols from /Users/a3r7lzz/Coding/gdb/test.dSYM/Contents/Resources/DWARF/test...
(gdb) run
Starting program: /Users/a3r7lzz/Coding/gdb/test
[New Thread 0x1803 of process 3054]
at this point nothing happens... it just hangs and can't kill it with Ctrl-C, I have to go to the activity monitor to kill gdb. Wondering if I have missed something in my setup, or if anyone has any other ideas why this might be
so before using gdb you have to create a ".gdbinit" file in your home directory.
Now every time gdb starts it will execute the commands in this file. ".gdbinit" is a file you can drop in your home directory that gdb will parse when gdb launches, either from the command line or from within Xcode.
echo "set startup-with-shell off" >> ~/.gdbinit
run this command and gdb won't hang when you use run command aur r.
You can kill the hang with Ctrl-Z.
Try running it several times, when setup correctly it seems to only work sometimes.
This hang hits gdb bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24069
You can install gdb from this source with patch:
brew install --force --build-from-source domq/gdb/gdb # a patched version based on 10.1
or you can
brew update
brew install gdb # use gdb 12.1
It works for me, and I found it from this link: https://gist.github.com/mike-myers-tob/9a6013124bad7ff074d3297db2c98247
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
gdbserver localhost:2159 test_app.exe
Whenever I type this kind of command
I got this kind of message:
glob could not process pattern '(null)'.
Also, it doesn't matter which kind of terminal/CLI I use on my Windows machine -
the result is always the same.
I would like to debug my PDCurses/NCurses app via CLion.
Every time when it encounters the initscr() function CLion says to me that:
Redirection is not supported.
So the only workaround seems to be the usage of GDB Remote Debug.
But due to the problem described above I am not sure if my settings are correct.
$ gdbserver --version
GNU gdbserver (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "x86_64-w64-mingw32"
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.
I'm rebuilding a flash loader utility for a TI chip and am facing a minor issue that's affecting my workflow. I'm using a 64-bit Win7 PC and rebuilding the utility using make on cygwin bash shell. make and cygwin version numbers below.
$ make -v
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010 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.
$ uname -a
CYGWIN_NT-6.1-WOW64 DEEDAA 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
One step in the build process calls a previously generated utility (windows executable) to generate the bin file that is required for the TI processor.
../../AISUtils//HexAIS_OMAP-L138.exe -ini ../sft_hexais.ini -o ../sft_C6748_SPI_MEM.bin ../sft_C6748_SPI_MEM.out
After this command is called there is no progress seen on the cygwin command line. However, execution of the command does complete, generating the files specified in this step and proceeds with the steps that follow in the makefile. It's just that I can never regain control of this window. I always need to kill the window, start another instance of cygwin.
If I try to kill the cygwin window immediately I get the message below.
mintty
Processes are running in session
Close anyway?
If I wait a while (the time to complete the steps that follow), then I can kill the window without this message popping up.
The same command on the windows command line is executed without any stalls and I do regain my command line.
c:\ti\boot_tools\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU\AISUtils>HexAIS_OMAP-L138.exe -ini ..\sft\sft_hexais.ini
-o ..\sft\sft_C6748_SPI_MEM.bin ..\sft\sft_C6748_SPI_MEM.out
-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------
Begining the AIS file generation.
AIS file being generated for bootmode: UART.
Parsing the input object file, ..\sft\sft_C6748_SPI_MEM.out.
AIS file generation was successful.
Wrote 15464 bytes to file ..\sft\sft_C6748_SPI_MEM.bin.
Conversion is complete.
It seems to me that something about the way the command is constructed is pushing commands on to another shell or forcing it to run in the background. Any thoughts on what may be going on or steps I can try to debug the issue?
file format of the executable that stalls
$ file AISUtils/HexAIS_OMAP-L138.exe
AISUtils/HexAIS_OMAP-L138.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Link to TI wiki that explains the build process. The link provides general instructions on rebuilding the utility and is very unlikely to provide any specific information related to my question. I'm only including it in case someone needed more background about the tools or the process.
http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package
Thanks.
Running Windows console applications inside a Cygwin (MinTTY) terminal is usually a terrible idea.
Try running inside a Windows (cmd) console or using cygstart to launch in a new window (in a Makefile, -w would probably be useful too).