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"
Related
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
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.
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 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.
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).