I'm using clion to write a console application. If I simply run the program, I can see the results of my cout calls. But if I debug it, no output occurs under the Debug Console tab other than my exe's name and Process finished with exit code 0. Is there an extra step to get console output to show up under debug in clion?
Or is this not even clion specific and is a general thing people who have been using gdb already know about?
According to the JetBrains'post on clion debugger, you can see the debug output by click the "Console" tab, which is next to "Debugger" tab:
GDB manipulates the process of running a program.
An example of GDB session:
% cat hello.c
#include<stdio.h>
main() {
int count;
for (count=0;count<10;count++)
printf("Hello from CETS!\n");
}
% gcc -g hello.c
% gdb ./a.out
GDB is free software and you are welcome to 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.
GDB 4.13 (sparc-sun-solaris2.3),
Copyright 1994 Free Software Foundation, Inc...
(gdb) b main
Breakpoint 1 at 0x10784: file hello.c, line 6.
(gdb) r
Starting program: /home1/b/bozo/./a.out
Breakpoint 1, main () at hello.c:6
6 for (count=0;count<10;count++)
(gdb) s
7 printf("Hello from CETS!\n");
(gdb) p count
$1 = 0
(gdb) disp count
1: count = 0
(gdb) set count=8
(gdb) s
Hello from CETS!
6 for (count=0;count<10;count++)
1: count = 8
(gdb)
7 printf("Hello from CETS!\n");
1: count = 9
(gdb) c
Continuing.
Hello from CETS!
Program exited with code 01.
(gdb) q
%
Content that might be helpful for you:
http://www.cs.swarthmore.edu/~newhall/unixhelp/howto_gdb.html
http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#GDB
http://www.seas.upenn.edu/cets/answers/gcc.html
Related
This is a follow-up question that originates from the answer from thiefmaster to this question: gdb input redirection using cygwin
I am a beginner, so kindly pardon my ignorance.
I want to know how to redirect input to gdb using a text file while using a command-line argument? if you can elaborate the answer, it would be better. When should I enter command-line argument -f filename. i.e.
i tried following but it didn't work
gcc -g testing3.c -o testing 3.exe
gdb testing3.exe
b main // to ensure it breaks on main
run -f userinput.txt
I have installed cygwin for compiling, running and debugging c
programs. (CYGWIN_NT-10.0-18363 version 3.3.3-341.x86_64)
My userinput.txt is also saved in the same location as the pwd of gdb
I have tried all the following ways, but none seem to work:
attempt#1
gdb ./testing3.exe -i userinput.txt
output of gdb is
Interpretor 'userinput.txt' unrecognized
attempt#2
gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
gdb output is as follows: basically, it still asks for input from STDIN interactively rather than reading from userinput.txt
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 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-pc-cygwin".
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 ./exercise5-7.exe...
(gdb) r
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 28036.0x1a48]
[New Thread 28036.0x6cbc]
[New Thread 28036.0x5ab0]
readlines: user input would start shortly
[New Thread 28036.0x4f74]
i am
manually
typing the
input
writelines
i am
manually
typing the
input
[Thread 28036.0x1a48 exited with code 0]
[Thread 28036.0x6cbc exited with code 0]
[Thread 28036.0x6e30 exited with code 0]
[Thread 28036.0x4f74 exited with code 0]
[Inferior 1 (process 28036) exited normally]
(gdb)
attempt#3
gdb ./testing3.exe
b main
r
call dup2(open("userinput.txt",0),0)
gdb outputs
'open' has unknown return type; cast the call to its declared return type
Edit #2: basis comments from matzeri and ssbssa
I tried the suggestion. following is the gdb output:
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ cat userinput.txt
God
is
great
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 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-pc-cygwin".
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 exercise5-7.exe...
(gdb) b main
Breakpoint 1 at 0x100401090: file exercise5-7.c, line 12.
(gdb) delete 1
(gdb) i b
No breakpoints or watchpoints.
(gdb) run < userinput.txt
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 22400.0x70d4]
[New Thread 22400.0x70e0]
[New Thread 22400.0x719c]
readlines: user input would start shortly
[New Thread 22400.0x1bec]
God
is still
great
writelines
God
is still
great
[Thread 22400.0x70f0 exited with code 0]
[Thread 22400.0x70e0 exited with code 0]
[Thread 22400.0x70d4 exited with code 0]
[Thread 22400.0x1bec exited with code 0]
[Inferior 1 (process 22400) exited normally]
(gdb)
it basically asks for user input from the STDIN and ignores the userinput.txt file. the messages readlines: use input would start shortly and writelines are my print statements in the code.
I am trying to debug AVX-512 instructions on an emulated CPU using Intel® Software Development Emulator but it doesn't work as desired after setting a breakpoint. I followed this blog post: Debugging Emulated Code on Linux*
In window #1:
~$ g++ -g -O0 -mavx512f main.cpp -o main # compile main.cpp file
~$ sde -debug -- ./main # enable debugging
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :54105
In window #2
# run debugger
~$ gdb ./main
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 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-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"...
Reading symbols from ./main...
# set target "target remote :portnumber"
(gdb) target remote :54105
Remote debugging using :54105
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa7bbbcc100 in ?? () from /lib64/ld-linux-x86-64.so.2
# suspend program at main function
(gdb) break main
Breakpoint 1 at 0x2c9c: file /home/borrow/source/repos/se-test/main.cpp, line 165.
# start program execution from the beginning of the program
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
# step to next line of code
(gdb) step
Cannot find bounds of current function
# continue executing until next break point
(gdb) c
Continuing.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
[Inferior 1 (Remote target) exited normally]
In window #2: as you can see
gdb run should run a program but it doesn't work. gdb c should also run until the next breakpoint but executes the program and terminates. This command gives me the following warning message:
warning: Probes-based dynamic linker interface failed.
In window #1: The program runs and ends (without stopping).
Program code looks like this:
// main.cpp
#include <immintrin.h>
const int N=64;
int64_t srcA[N] = {0};
int64_t srcB[N] = {0};
int64_t dst[N] = {0};
void foo()
{
__m512i result,B,C;
for ( int i=0; i<N; i+=8 ){
B = _mm512_loadu_si512(&srcA[i]);
C = _mm512_loadu_si512(&srcB[i]);
result = _mm512_add_epi64(B,C);
_mm512_storeu_si512(&dst[i], result);
}
}
int main() {
...
foo();
...
}
I tried running AVX2 code without SDE emulator using gdb and it worked. First I start it on an emulated CPU with SDE, it fails. How can I solve this problem?
It seems to be broken for PIE executables
(confirmed on Arch GNU/Linux with GCC 10.2, GDB 10.1, SDE 8.33.)
Build with g++ -O2 -fno-pie -no-pie -g -march=skylake-avx512 and everything works. (I had to run gdb ./a.out instead of bare GDB; without that it couldn't find the right file even after connecting to the remote.)
$ g++ -O2 -march=skylake-avx512 -no-pie -fno-pie -g avx512.cpp
$ /opt/sde-external-8.33.0-2019-02-07-lin/sde64 -debug -- ./a.out
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :59783
Then in another terminal tab
$ gdb ./a.out
...
(gdb) target remote :59783
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f4f7033b090 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x401050: file avx512.cpp, line 29.
(gdb) b foo
Breakpoint 2 at 0x401190: file avx512.cpp, line 14.
(gdb) c
Continuing.
Breakpoint 1, main () at avx512.cpp:23
(gdb) layout asm
(copy-paste of some of the disassembly window)
│B+ 0x401120 <_Z3foov> xor eax,eax
│ 0x401122 <_Z3foov+2> nop WORD PTR [rax+rax*1+0x0]
│ >0x401128 <_Z3foov+8> vmovdqu64 zmm1,ZMMWORD PTR [rax+0x404260]
│ 0x401132 <_Z3foov+18> add rax,0x40
│ 0x401136 <_Z3foov+22> vpaddq zmm0,zmm1,ZMMWORD PTR [rax+0x404420]
│ 0x401140 <_Z3foov+32> vmovdqu64 ZMMWORD PTR [rax+0x404020],zmm0
│ 0x40114a <_Z3foov+42> cmp rax,0x200
│ 0x401150 <_Z3foov+48> jne 0x401128 <_Z3foov+8>
│ 0x401152 <_Z3foov+50> vzeroupper
│ 0x401155 <_Z3foov+53> ret
(gdb) layout src
asm-level and source-level debugging both work fine, stepping into intrinsic "functions" in avx512fintrin.h and so on when using stepi (aka si).
Without specifying the filename separately from connecting to the remote:
$ gdb
(gdb) target remote :46879
Remote debugging using :46879 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command.
0x00007f0f85830090 in ?? ()
(gdb)
(IDK if it matters that my .gdbinit includes layout reg, the full-screen terminal TUI mode. Nice when it works but somewhat buggy.)
Or as a super hacky workaround with PIE executables, I was also able to put a delay loop at the top of main, giving you a chance to attach and then control-C before SDE finishes executing your program.
Then I could set breakpoints and start single-stepping. (Presumably a sleep or read system call would work). Source-level debugging still seemed broken, but I was able to debug the asm with layout reg. I used set $rip = ... with a copy-pasted address to get out of the _mm_pause() loop after attaching and hitting control-C.
I go this simple code to test my GDB ( GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1), my linux runs within docker, and the code is:
// hello.cc
#include <iostream>
int main() {
std::cout << "hello world!" << std::endl;
}
I compiled it with:
$ g++ -g -o out.a hello.cc
and debug it like:
(gdb) file out.a
(gdb) b main
Note: breakpoint 1 also set at pc 0x40084a.
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000040084a in main() at hello.cc:3
(gdb) r
hello world!
During startup program exited normally.
Why gdb not stopped on main?
Couple of reasons i can think of:
The gdb version i use is 7.0-0.4.16, and it worked as expected (ie., stopped at main). Probably it is related to version of gdb you have.
I am bit surprised on the info output in your gdb case. It showed the line number as '3' for breakpoint. Ideally it should be 4.
Ruling out the other two options mentioned above. Just observed that your linux is running on a docker. In this case, your test program is a process running on the docker and i assume gdb is invoked on native machine. You might need to attach the docker to gdb using lxc-attach.
I'm trying to get to the bottom of a bug in KDE 5.6. The locker screen breaks no matter how I lock it. Here's the relevant code: https://github.com/KDE/kscreenlocker/blob/master/abstractlocker.cpp#L51
When I run /usr/lib/kscreenlocker_greet --testing, I get an output of:
KCrash: Application 'kscreenlocker_greet' crashing...
Floating point exception (core dumped)
I'm trying to run it with gdb to try and pin the exact location of the bug, but I'm not sure where to set the breakpoints in order to isolate the bug. Should I be looking for calls to KCrash? Or perhaps a raise() call? Can I get gdb to print off the relevant line of code that causes SIGFPE?
Thanks for any advice you can offer.
but I'm not sure where to set the breakpoints in order to isolate the bug
You shouldn't need to set any breakpoints at all: when a process running under GDB encounters a fatal signal (such as SIGFPE), the OS notices that the process is being traced by the debugger, and notifies the debugger (instead of terminating the process). That in turn causes GDB to stop, and prompt you for additional commands. It is at that time that you can look around and understand what caused the crash.
Example:
cat -n t.c
1 #include <fenv.h>
2
3 int foo(double d) {
4 return 1/d;
5 }
6
7 int main()
8 {
9 feenableexcept(FE_DIVBYZERO);
10 return foo(0);
11 }
gcc -g t.c -lm
./a.out
Floating point exception
gdb -q ./a.out
(gdb) run
Starting program: /tmp/a.out
Program received signal SIGFPE, Arithmetic exception.
0x000000000040060e in foo (d=0) at t.c:4
4 return 1/d;
(gdb) bt
#0 0x000000000040060e in foo (d=0) at t.c:4
#1 0x0000000000400635 in main () at t.c:10
(gdb) q
Here, as you can see, GDB stops when SIGFPE is delivered, and allows you to look around and understand the crash.
In your case, you would want to first install debuginfo symbols for KDE, and then run
gdb --args /usr/lib/kscreenlocker_greet --testing
(gdb) run
How does one set a breakpoint in a file that has a space in its filename or path?
It seems like this is not possible with GDB or am I missing something?
/tmp$ g++ -g debugee\ space.cpp
/tmp$ gdb ./a.out
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/a.out...done.
(gdb) break "/tmp/debugee space.cpp:4"
Breakpoint 1 at 0x4007e3: file debugee space.cpp, line 4.
(gdb) break "/tmp/debugee space.cpp":4
Note: breakpoint 1 also set at pc 0x4007e3.
Breakpoint 2 at 0x4007e3: file debugee space.cpp, line 4.
(gdb) run
Starting program: /tmp/a.out
Error in re-setting breakpoint 1: Function "/tmp/debugee space.cpp:4" not defined.
Error in re-setting breakpoint 2: Function "/tmp/debugee space.cpp:4" not defined.
Hello, world!
[Inferior 1 (process 14188) exited normally]
(gdb)
To me this looks like a regression in gdb 7.4. I reported the bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13798
works for me (tm), didn't try with c++ though...
cat space\ spaces.c
#include <stdio.h>
int tmp(void) {
int a = 42;
printf("%d", a);
}
int main(void) {
tmp();
return 0;
}
$ gdb -q a.out
Reading symbols from /home/user/slask/gdb/a.out...done.
(gdb) b "space spaces.c":5
Breakpoint 1 at 0x4004f3: file space spaces.c, line 5.
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004004f3 in tmp at space spaces.c:5
(gdb) run
Starting program: /home/user/slask/gdb/a.out
Breakpoint 1, tmp () at space spaces.c:5
5 printf("%d", a);
(gdb)