I am using KDevelop as IDE for my C++ program. I have an array char buffer[1024] in my program. After reading data to buffer, I would like to check it manually. But in the left panel, I need to read the array character by character. Is there some way by which I can get the content of the array at a stretch?
Use GDB tool view available in KDevelop. In KDevelop 4.6, Window->Add ToolView->GDB will open the GDB tool view at the bottom/left/right of KDevelop IDE. Debug your program and at the point at which you have to check value of the variable, enter print variable_name in the textbox corresponding to GDB cmd. The value of variable will be printed.
Some example commands:
Show an array (will show first 200 elements by default):
(gdb) print buffer
print buffer
$1 = "\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?#ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307"...
Show an array range buffer[index]#count:
(gdb) print buffer[50]#40
print buffer[50]#40
$2 = "23456789:;<=>?#ABCDEFGHIJKLMNOPQRSTUVWXY"
There's the Variables tool view.
Show it by right clicking left, right or bottom border of KDevelop's window and click Variables
Related
int a[10000];
for(int i=0;i<10000;i++)
{
a[i]=i; cout<<a[i]<<endl;
}
Suppose this is the code and on the terminal screen I need all outputs (0-9999) But it only displays (9704-9999) at the end
I want to see all the numbers on the terminal window but it removes the upper part of the data. I guess I have to change some settings.
Increase the console buffering. Depending on which terminal you're using it'll be different. For example on Windows conhost.exe is the default console used by cmd and PowerShell. Just click the icon on the top left > Properties > Layout and set Screen Buffer Size to a large enough number
But the better solution would be redirecting to file, because no one wants to read 10000 lines on the console, and there's no guarantee that the console will have a buffer of infinite length or length of more than 10000 lines. conhost for example only supports maximum 9999 lines so you'll miss at least the command you typed and the first output line. Besides that'll often remove other commands' output from the history which is undesirable
Either do that from the command line with the redirection operator >
yourapp.exe >output.txt
or save to file directly from your code
This answer is based on a comment by bcumming in How do I print the elements of a C++ vector in GDB? and was tested with Codelite 10.0.0, gcc 4.9.2 and gdb 7.7.1 on 64 bit Debian 8. That question concerned displaying all the elements of the vector. The answer by John Carter had the disadvantage of involving internal library-dependent pointer names and the advantage that it works fine even if the inferior (the program being debugged) did not have compiled into it the code for operator [ ]. (See: gdb Could not find operator[].)
If I want to see 4 elements of vector vecVp starting with index [3] then the gdb print command is:
p *(&vecV[3]) # 4
This is my answer. I have been trying to figure out how to do this for years, and it is not in the gdb manual, as far as I know. The text below concerns variations of and the principles behind this technique.
One reason for doing this is to reduce the clutter of displaying all the elements of a vector. The other is to reduce the time it takes gdb to respond for the Watch window lines, such as for each "step over" IDE operation. I find that gdb, with its Python-based STL pretty printing mechanisms, can take seconds or tens of seconds to respond to large numbers of simple elements, or few more complex ones.
This is an application to vectors of the technique described in gdb manual section 10.4 Artificial Arrays where the binary operator # works fine with C-style arrays: p arrA[3] # 4 but not vectors and the like from the containers library (STL).
The above use of #, starting with a particular vector element, works fine in Codelite's Watch window, where the p part above is not needed. The single line which Codelite displays can be opened up by clicking right-pointing arrows to show all the values of the elements and the objects, vectors of strings etc. that they contain. However, it does not work as the basis for displaying just just one inner element, such as some class object, an int or a string, of each of the range of vector elements. To do this, four Watch lines must be created (add p for driving gdb directly):
vec[3].log
vec[4].log
vec[5].log
vec[6].log
This of course is tedious. The solution is to add some variables to the inferior which are only to be used by gdb. These can be static, outside any function and so "global":
static int XX = 0;
static int YY = 0;
static int ZZ = 0;
Their values can be set from within Codelite, while the inferior is paused at a breakpoint, by commands such as set XX = 3 entered into the "Send" bar at the bottom of the gdb console, which is under the "(red ladybug icon) Output" tab of the "Debugger" window. This enables me to use four Watch lines, each focused on just the "log" member of the four chosen elements in the vector, which can be easily steered to any part of the vector by altering the value of XX:
vecV[XX + 0].log
vecV[XX + 1].log
vecV[XX + 2].log
vecV[XX + 3].log
What's more, in my experience, changing XX causes Codelite to not only display the new data, but to highlight in red any which is different from what it displayed with the previous value of XX.
If log was an object containing a string which was too long to view in the Watch window (Settings > GDB Settings > GNU gdb debugger > General > Display > Number of elements to display for arrays/strings), then I can use the above scheme and substr() with some other gdb-set variables to control which range of the strings are displayed:
vecV[XX + 0].log.strS.substr(AA, BB)
vecV[XX + 1].log.strS.substr(AA, BB)
vecV[XX + 2].log.strS.substr(AA, BB)
vecV[XX + 3].log.strS.substr(AA, BB)
Such variables can be applied to the main technique to provide a steerable, resizable, window of display into a vector, by typing one or two commands to the gdb console, rather than editing the Watch window line, which typically involves lots of mouse/trackball clicking to re-open all the branches of the objects which are of interest:
(&vecV[YY]) # ZZ
DBMS_OUTPUT.PUT_LINE( ) doesn't print output however output and spooling are turned on. "Procedure is completed successfully" message is displayed without any output. When run in SQLPLUS it throws errors.
Do you have any idea to check? I tried the DBMS_OUTPUT.ENABLE() etc.
Make sure you "execute as a script" by pressing F5. Make sure the editor window has this line before calling your procedure:
set serveroutput on size unlimited;
Here is an example calling a homegrown function that returns an element from a list (in this case the 6th element, "mirror") where the delimiter is a space. Note you can view output on the "DBMS Output" tab too (click the "turn output on" button first).
Click on the image to view full size
i found this little tricky button in jetBrains Datagrip, it turns on dbms_output without any dbms_output.enable or set serveron etc.
I've set a breakpoint in gdb, and I'd like to see the exact line of source the breakpoint is on, just to confirm it's correct -- is there a quick way to do this?
The "info b" command gives me information about the breakpoints, but it doesn't display source:
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000006c3ba4 in MyClass::foo(bar*)
at /home/user1/src/MyClass.cpp:1021
I can type "list MyClass.cpp:1021" to see the lines around this breakpoint, but I'm wondering if there's a shorter way. Googling and reading the gdb manual didn't turn up anything.
I know that if I'm executing the program and have hit the breakpoint, I can just type "list", but I'm asking specifically about the case where I am not at the breakpoint (the program may not even be running).
You can use the list command to show sources. list takes a "linespec", which is gdb terminology for the kinds of arguments accepted by break. So, you can either pass it whatever argument you used to make the breakpoint in the first place (e.g., list function) or you can pass it the file and line shown by info b (e.g., list mysource.c:75).
I think the closest one can get to this is by turning the history on (set history save on) and then press CTRL-R to do a reverse search for the former list command.
More specifically, change your workflow when setting a breakpoint. After each command like b main GDB shows the source file like path/to/main.cpp, line 12. Immediately use this information in a quick list main.cpp:12. To show this location later press CTRL-R and type "main".
https://sourceware.org/gdb/onlinedocs/gdb/Command-History.html
I'm a Vim user and don't know much about Emacs. I'm interested with Emacs because I find that debugging within Emacs is more pleasant. For example, it provides syntax highlighting and I can set breakpoints with the mouse.
Everything works well except when printf is encountered.
Simple code for illustration:
1 #include <stdio.h>
2
3 int main()
4 {
5 int a = 1;
6 printf("%d\n", a);
7 int b = 2;
8 return 0;
9 }
emacs main.c
left click on the bottom half
M-x gdb[return][return]
(gdb) b 6
(gdb) r
By now, the source codes are showed in the upper half, and gdb prompt in the bottom half. This is exactly what I want.
(gdb) n
Now the source codes disappear, and the upper half is used to show stdout instead. This is really inconvenient. I'd like the stdout to show in the gdb buffer, and the sources stay in the upper buffer, just as the gdb -tui mode.
Instead of manually setting up your splits each time, try telling GDB which windows you want available.
For example:
;; Show main source buffer when using GDB
(setq gdb-show-main t)
Now you can simply use M-x gdb to start GDB, and it should keep your source code buffer displayed in a split window.
Incidentally, Emacs' GDB interface supports a number of other windows that you may want to enable:
If gdb-many-windows is non-nil, then M-x gdb displays the
following frame layout:
+--------------------------------+--------------------------------+
| GUD interaction buffer | Locals/Registers buffer |
|--------------------------------+--------------------------------+
| Primary Source buffer | I/O buffer for debugged pgm |
|--------------------------------+--------------------------------+
| Stack buffer | Breakpoints/Threads buffer |
+--------------------------------+--------------------------------+
If you ever change the window layout, you can restore the "many
windows" layout by typing M-x gdb-restore-windows. To toggle between
the many windows layout and a simple layout with just the GUD
interaction buffer and a source file, type M-x gdb-many-windows.
You may also specify additional GDB-related buffers to display,
either in the same frame or a different one. Select the buffers you
want by typing M-x gdb-display-BUFFERTYPE-buffer or M-x gdb-frame-BUFFERTYPE-buffer, where BUFFERTYPE is the relevant buffer
type, such as breakpoints. You can do the same with the menu bar,
with the GDB-Windows and GDB-Frames sub-menus of the GUD menu.
When you finish debugging, kill the GUD interaction buffer with C-x k,
which will also kill all the buffers associated with the session.
However you need not do this if, after editing and re-compiling your
source code within Emacs, you wish to continue debugging. When you
restart execution, GDB automatically finds the new executable. Keeping
the GUD interaction buffer has the advantage of keeping the shell
history as well as GDB's breakpoints. You do need to check that the
breakpoints in recently edited source files are still in the right
places.
You might also like to try M-x gud-gdb. It's a much more bare-bones UI, but I personally prefer it.