I am trying to import all the function symbols in the elf with the function base address to a text file.
I am using the below 2 commands to do that
PRinTer.FILE c:\temp\function_symbol.txt
WinPrint.symbol.list.function
But in this process, full function name is getting terminated. I am getting output like this:
__________address________|path\symbol_|type_____________________|scope_|location|info
P:C001608C--C00160E7|.sym_1\sym_2|(static void * ()) |module|static |frame: * . push
I want the address and full path\symbol(2nd column). Please note that the symbol table is very big and increasing clip board size and selecting "To Clipboard All" will not work. I know that if I have the function base address , I can get the function name. But, in my implementation, I need to know both base address and function full name for better efficiency.
I want to know if it is possible to increase width of 2nd column via some command so that I get full function names after using winprint command
The window sYmbol.List.Function has two columns (with white background) which have a flexible width. You can control the width of those flexible columns with the command WinTABS.
Thus, to export sYmbol.List.Function with a wide column for "path\symbol" use the following commands:
PRinTer.FILE c:\temp\function_symbol.txt ASCIIE
WinTABS 1000.
WinPrint.sYmbol.List.Function
By the way: The width of the address column on the left of the window (with gray background) is controlled via the 5th parameter of the WinPOS command.
Related
I was trying to run the code and it keeps showing the same error.
I start by compiling with ocamlc -o cardioide graphics.cma cardioide.ml and it appears to work, but then I do ./cardioide to execute it and the message Fatal error: exception Graphics.Graphic_failure("Cannot open display ") appears...
I've searched all across the internet and i can't find the solution, can someone please help me?
Thank you
open Graphics
let () = open_graph "300x20"
let () =
moveto 200 150;
for i = 0 to 200 do
let th = atan 1. *. float i /. 25. in
let r = 50. *. (1. -. sin th) in
lineto (150 + truncate (r *. cos th))
(150 + truncate (r *. sin th))
done;
ignore (read_key ())
Error message:
Fatal error: exception Graphics.Graphic_failure("Cannot open display ")
The string argument to the open_graph function is not the size or title, but actually implementation-dependent information that is passed to the underlying graphical subsystem (in X11 it is the screen number). In modern OCaml, optional arguments are passed using labels, but Graphics was written long before this feature was introduced to the language. Therefore, you have to pass an empty string there (if you don't want to pass any specific to implementation of the underlying graphical subsystem information), e.g.,
open_graph ""
will do the work for you in a system-independent way.
Besides, if you want to resize the window, then you can use the resize_window function. And to set the title, use set_window_title.
For the historic reference, the string parameter passed to the open_graph is having the following syntax (it is no longer documented, so there is no reason to believe that it will be respected):
Here are the graphics mode specifications supported by
Graphics.open_graph on the X11 implementation of this library: the
argument to Graphics.open_graph has the format "display-name
geometry", where display-name is the name of the X-windows display
to connect to, and geometry is a standard X-windows geometry
specification. The two components are separated by a space. Either
can be omitted, or both. Examples:
Graphics.open_graph "foo:0" connects to the display foo:0 and creates a
window with the default geometry
Graphics.open_graph "foo:0 300x100+50-0" connects to the display foo:0 and
creates a window 300 pixels wide by 100 pixels tall, at location (50,0)
Graphics.open_graph " 300x100+50-0" connects to the default display and
creates a window 300 pixels wide by 100 pixels tall, at location (50,0)
Graphics.open_graph "" connects to the default display and creates a
window with the default geometry.
Put a 'space' in the argument to get the window you want (should be 200 for your cardioide):
let () = open_graph " 300x200"
I met the same problem and it was because I used the Windows subsystem for linux(WSL) so it needs a XServer to run graphical application. And the Ubuntu Wiki For WSL helped solve the problem. I downloaded and installed MobaXterm (it has free community version!) and it automatically detects the WSL and runs it inside the app. Try the same code before and a graphical window will pop up!
I am using GWBASIC and cannot figure out a few things. Like, when I'm saving a program after running it with F4, it says: File not found.
Secondly, when I'm using auto command it shows * with line numbers.
Finally, if I want to take program and its output's print on paper, what should I do?
I am using GWBASIC and cannot figure out a few things. Like, when I'm
saving a program after running it with F4, it says: File not found.
Try saving like this:
SAVE"myprog.bas",a
Secondly, when I'm using auto command it shows * with line numbers.
The star (*) on a line means that line already exists and you are overwriting it.
If you use the command NEW to wipe-out the program from memory before running 'auto', you won't see those stars on lines.
Finally, if I want to take program and its output's print on paper,
what should I do?
1) Save the program as a text file:
SAVE"myprog.bas",a
2) Open the file 'myprog.bas' with a text editor (like Notepad++).
3) Print it.
To print a GW-BASIC program, use the LIST command.
The optional , filename parameter specifies the output for the listing. It could be to a file (e.g. to dump the text so another program can load it), or it could be to a printer device (e.g. LPT1:).
So this should work:
LIST ,LPT1:
See also https://robhagemans.github.io/pcbasic/doc/1.2/#LIST
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
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++)
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.