C++ gdb: How to display a range of elements in a vector and within that range, a subset of the elements' members? - c++

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

Related

Borland c++ console functions

I'm studing now and I got this homework / tasks to do:
1) If you press the CTRL + L key, all numeric symbols should change the color.
2) If you press the CTRL + S key, you will get the length of the word, left from the cursor.
I found this function int bioskey(int cmd);
So now I can check if the key is pressed, but how to change the color only of numeric symbols, or read words from console to get their length ?
Some of us still remember the MS-DOS (let it rest in peace or pieces...)
if you are really in MS-DOS then you can not expect that the content of the console would be changed in colors for only specific areas. You need to do that your self. The problem is we do not know anything about your project background so we do not know what and how yours stuff is represented,rendered/outputed/inputed etc...
I assume EGA/VGA BIOS text mode is used so you can exploit direct access to the VRAM. So you need to set pointer to the address B800:0000 and handle it as array where each character on screen has 2 BYTEs. one is color attribute and the other is ASCII code (not sure in which order anymore)...
So for already rendered stuff you just:
loop through whole screen
usually 80x25x2 Bytes
test each ASCII for alpha numeric value
so ASCII code >= '0' and code<='9' for numbers or add all the stuff you are considering as alphanumeric like code>' ' and code<='9'.
change colors for selected characters
just by changing the attribute byte.
When you put it together for numbers it will look like this:
char far *scr=(char far*)0x0B0000000;
int x,y,a;
for (a=0,y=0;y<25;y++)
for (x=0;x<80;x++,a+=2)
if ((scr[a+0]>='0')&&((scr[a+0]<='9'))
{
scr[a+1]=7; //attribute with the different color here
}
if it does not work than try swap scr[a+0] and scr[a+1]. If an exception occur then you are not in MS-DOS and you do not have access to VRAM. In that case use DOS-BOX or driver that allows access to memory like dllportio ...
For more info see some more or less related QA's:
Display an array of color in C
What is the best way to move an object on the screen?
If you got problem with the CTRL+Key detection not sure if in-build function in TC++ allows CTRL (was too long ago) then you can exploit BIOS or even hook up the keyboard ISR. See the second link where ISR for keyboard handler is there present... You can port it to C++ or google there must be a lot of examples out there especially TP7.0 (which is pascal but easily portable to TC++)

gnuradio: how to change the noutput_items dynamically when writing OOT block?

When I make a OOT block in gnuradio
class mod(gr.sync_block):
"""
docstring for block mod
"""
def __init__(self):
gr.sync_block.__init__(self,
name="mod",
in_sig=[np.byte],
out_sig=[np.complex64])
def work(self, input_items, output_items):
in0 = input_items[0]
out = output_items[0]
result=do(....)
out[:]=result
return len(output_items[0])
I get:
ValueError: could not broadcast input array from shape (122879) into shape (4096)
How can I solve it?
GRC is as below:
selector :input index and output index are controlled by WX GUI Chooser block
FSK4 MOD: modulate fsk4 signal and write data to raw.bin
FSK4 DEMOD : read data from raw.bin and demodulate
file source -> /////// -> FSK4 MOD -> FSK4 DEMOD -> NULL SINK
selector
file source -> ////// -> GMKS MOD -> GMSK DEMOD ->NULL SINK
when the input index or output index is changed,the whole flow graph will be not responding.
There's two things:
You have a bug somewhere, and the solution is not to change something, but fix that bug. The full Python error message will tell you exactly in which line the error is.
noutput_items is a variable that GNU Radio sets at runtime to let you know how much output you might produce in this call to work. Hence, it's not something you can set, but it's something your work method must respect.
I think it's fair to assume that you're not very aware of how GNU Radio works:
GNU Radio is based on calling your block's work function when there is enough output space available and enough input items to process. The amount of output space that your block can use is passed to your work as a parameter, and will change between calls to work.
I very strongly recommend going through chapters 1-3 of the official Guided Tutorials if you haven't already. We always try to keep these tutorials up-to-date.
EDIT: Your command shows that you have not really understood what I meant, sorry. So: GNU Radio calls your work method over and over again while it's executing.
For example, it might call work with 4000 input items and 4000 output items space (you have a sync block, therefore number of input==number of output). Your work processes the first 1000 of that, and therefore return 1000. So there's 3000 items left.
Now, the upstream block does something, so there's 100 new items. Because the 3000 from before are still there, your block's work will get called with 3100 items.
Your work processes any number of items, and returns that number. GNU Radio makes sure that the "remaining" items stay available and will call your work again if there is enough in- our output.

How to view values of variables in KDevelop?

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

Use gdb within Emacs: always show the source code

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.

Debugging C++ in an Eclipse-based IDE - is there something like "step over loop/cycle"?

At the moment I'm using an eclipse-like IDE and the corresponding debug perspective, that most of you are probably familiar with. While debugging code I quite often find myself stepping through many lines of code and observing variables and double checking if everything is as it is supposed to be.
But suppose there is something like this:
1. important line, e.g. generating a new object;
2. another important line, e.g. some tricky class method;
3. for (int i = 0; i < some_limit; ++i)
4. some_array[i]++;
5. more important stuff;
Obviously I'm interested in what happens in lines 1,2 and 5 (I know this is a poor example, but please bear with me for a little while longer) but I don't want to step through all hundreds (or even thousands) of iterations of lines 3/4.
So, finally, my question: Is there some way to step directly over the for-cycle? What I do right now is set a new breakpoint at line 5 and let the program run as soon as I hit line 3 and I believe this is not an optimal solution.
edit: The eclipse implementation of what ks1322 proposed is called "Run to line" and is mapped to ctrl-r
Use until command instead of next.
From gdb documentation:
Continue running until a source line past the current line, in the
current stack frame, is reached. This command is used to avoid single
stepping through a loop more than once.
If you will use until instead of next, gdb will step over loops only once, which almost exactly what you want.