In GDB it is possible to step multiple instructions with a single command. After much searching, it does not appear to be possible to do the same in LLDB.
For example, in GDB, if you enter si 5, you will step forward 5 instructions. However, doing the same in LLDB results in:
error: Thread index 5 is out of range (valid values are 0 - 1).
In GDB running si with an integer defines how many instructions to step, but in LLDB it defines which thread to step forward 1 instruction.
Is there any way to step forward multiple instructions in LLDB as can be done in GDB?
This is an enhancement that is on our queue, but somehow never makes it to the top. I added a --count option to step-inst & step-next-inst as my lunch time hack. It's in TOT lldb, can't say when it will make it into an official Apple release.
If you're stuck on an older version of LLDB and don't have the feature which was implemented after this question was asked, or simply want to automate repeating any arbitrary commands, here is a quick-and-dirty way of scripting multiple commands which can be entered easily from the interactive LLDB python prompt:
lldb.debugger.SetAsync(False)
for _ in range(3): lldb.debugger.HandleCommand('si')
The above will make the API synchronous, so that each command will complete before running the next, and then loop executing commands (3 times in this example).
To access this prompt, enter the script command at the LLDB prompt, then Python away.
(lldb) script
Related
Most debuggers with GUI have a useful function run to cursor. Is there any similar way of doing this in gdb?
I'm talking about assembly mode debugging (without source code).
For example, it currently break at: 0x400000, I'd like to run to 0x400100, there're lots of instructions between them. To do this, I have to:
set breakpoint at 0x400100 with b *0x400100,
continue with c
delete breakpoint with d ...
It is lots of typing, and I need to do this frequently. Any simpler way of doing this?
You are looking for either "until" or "advance" command.
Details in GDB manual chapter Continuing and Stepping.
If stopping on frame exit is problematic, you can still use tbreak, which sets temporary breakpoint, which is automatically deleted once it is hit.
When executing next [count] or step [count] (e.g. next 10) in GDB, is there any way to display each line that gets executed, as if you had entered next or step [count] times?
I know that I can execute next once and then hold down the enter key for a while, but it's hard to precisely control where to stop when you do this.
gdb doesn't have a built-in way to do this.
You can do it by hand by writing a loop. This could be done from the CLI by using the define command to make a new command, like verbose-next that invokes next in a loop. Or, you could write it in Python; though in this case there's no particular advantage to doing so.
While debugging some code in gdb, I want to see which line will be executed if I say next or step.
Of course I can say l, but if I say l a couple times (and don't remember how many times), then l does not print the line that will be executed.
I can also scroll back to the last time gdb stopped and see which line it was at, but that sometimes involve digging through a bunch of output.
I am wondering if I am missing a simple command in gdb which shows me the current line the debugger is stopped at?
To see the current line the debugger stopped at, you can use frame command with no arguments. This achieves the same effect as update command. It works both in tui and command line mode.
You can use
list *$eip
or the shorter form
l *$eip
This will instruct gdb to print the source lines near the current program counter.
You can say l +0; the current line will be the first one listed.
The command l +offset lists the code starting from offset lines from the current line.
Note that, if you have already used the list command, the current line will have changed, i.e., it will no longer be the next executing line. So this will only work on your first list command.
It sounds like you want to run GDB in Emacs (which will show you current file and mark the current line), in DDD, or in tui mode.
I'm new to programming/development and I'm having trouble installing development tools.One of my biggest problems when installing something is understanding the shell or terminal (are they the same thing?) and how it relates to installing tools like uncrustify for example. What do I need to read to understand the shell/terminal and $PATH?
Have you tried Googling?
Environment variable
PATH (variable)
(I think you're getting good advice so far on PATH)
The most generic description of a shell is that is a program that facilitates interaction w programs. Programs facilitate 'communication' with the OS to perform work by the hardware.
There are two modes that you will normally interact with a shell.
a command-line processor, where you type in commands, letter-by-letter, word-by-word until you press the enter key. Then the shell will read what you have typed, validate that it understands the general form of what you have asked for, and then start running the 1 (or more) programs specified in what you have typed.
a batch-script processor. In this case you have assembled all of the commands you want executed into a file, and then thru 1 of several mechanisms, you arrange to have the batch-script run so it will in turn run the commands you have specified and the computer does your work for you. Have you done a Windows .Bat file? same idea, but more powerful.
So, a terminal widow is program that is responsible for a. getting input and b., printing output. When you get to the c-programming that underlies the Unix system, you are talking about a feature of the OS design which are called Standard In and Standard Out. Normal unix commands expect to read instructions from StdIn and print output to StdOut.
Of course, all good programs can get their input from files and write there output to files as well, and most programs will take over the StdIn/Out and process files instead of reading input from the keyboard and/or writing to the screen.
To return to the shell, this program that lets you type while the terminal window is open. There are numerous versions of the shell that you may run into AND have varying levels of features that support a. interactive-mode, b. batch-script mode.
To sum it up, here a diagram of what is involved (very basically) for terminal and shell
(run a) terminal-window (program)
shell-command-prompt (program) (automatically started as subprogram)
1. enter commands one at a time, with input from
a. typed at keyboard (std-in)
b. infile
and output to
a. screen (std-out)
b. outFile
program
calls OS level functions for
a. computation
b. I/O
OR 2.
(run the shell program without a terminal, usually from the cron sub-system)
shell-batch-processor
shell program reads batch-script file, 1 'statement' at a time
validate statements
run program, relying on script or cfg to provide inFile data and
indicate where to put outfile data.
I hope this helps.
This question already has an answer here:
How to abort a running program in MATLAB?
(1 answer)
Closed 7 years ago.
I write a long running script in Matlab, e.g.
tic;
d = rand(5000);
[a,b,c] = svd(d);
toc;
It seems running forever. Becasue I press F5 in the editor window. So I cannot press C-Break to stop in the Matlab console.
I just want to know how to stop the script. I am current use Task Manager to kill Matlab, which is really silly.
Thanks.
Matlab help says this-
For M-files that run a long time, or that call built-ins or MEX-files that run a long time, Ctrl+C does not always effectively stop execution. Typically, this happens on Microsoft Windows platforms rather than UNIX[1] platforms. If you experience this problem, you can help MATLAB break execution by including a drawnow, pause, or getframe function in your M-file, for example, within a large loop. Note that Ctrl+C might be less responsive if you started MATLAB with the -nodesktop option.
So I don't think any option exist. This happens with many matlab functions that are complex. Either we have to wait or don't use them!.
If ctrl+c doesn't respond right away because your script is too long/complex, hold it.
The break command doesn't run when matlab is executing some of its deeper scripts, and either it won't log a ctrl sequence in the buffer, or it clears the buffer just before or just after it completes those pieces of code. In either case, when matlab returns to execute more of your script, it will recognize that you are holding ctrl+c and terminate.
For longer running programs, I usually try to find a good place to provide a status update and I always accompany that with some measure of time using tic and toc. Depending on what I am doing, I might use run time, segment time, some kind of average, etc...
For really long running programs, I found this to be exceptionally useful
http://www.mathworks.com/matlabcentral/fileexchange/16649-send-text-message-to-cell-phone/content/send_text_message.m
but it looks like they have some newer functions for this too.
MATLAB doesn't respond to Ctrl-C while executing a mex implemented function such as svd. Also when MATLAB is allocating big chunk of memory it doesn't respond. A good practice is to always run your functions for small amount of data, and when all test passes run it for actual scale. When time is an issue, you would want to analyze how much time each segment of code runs as well as their rough time complexity.
Consider having multiple matlab sessions. Keep the main session window (the pretty one with all the colours, file manager, command history, workspace, editor etc.) for running stuff that you know will terminate.
Stuff that you are experimenting with, say you are messing with ode suite and you get lots of warnings: matrix singular, because you altered some parameter and didn't predict what would happen, run in a separate session:
dos('matlab -automation -r &')
You can kill that without having to restart the whole of Matlab.
One solution I adopted--for use with java code, but the concept is the same with mexFunctions, just messier--is to return a FutureValue and then loop while FutureValue.finished() or whatever returns true. The actual code executes in another thread/process. Wrapping a try,catch around that and a FutureValue.cancel() in the catch block works for me.
In the case of mex functions, you will need to return somesort of pointer (as an int) that points to a struct/object that has all the data you need (native thread handler, bool for complete etc). In the case of a built in mexFunction, your mexFunction will most likely need to call that mexFunction in the separate thread. Mex functions are just DLLs/shared objects after all.
PseudoCode
FV = mexLongProcessInAnotherThread();
try
while ~mexIsDone(FV);
java.lang.Thread.sleep(100); %pause has a memory leak
drawnow; %allow stdout/err from mex to display in command window
end
catch
mexCancel(FV);
end
Since you mentioned Task Manager, I'll guess you're using Windows. Assuming you're running your script within the editor, if you aren't opposed to quitting the editor at the same time as quitting the running program, the keyboard shortcut to end a process is:
Alt + F4
(By which I mean press the 'Alt' and 'F4' keys on your keyboard simultaneously.)
Alternatively, as mentioned in other answers,
Ctrl + C
should also work, but will not quit the editor.
if you are running your matlab on linux, you can terminate the matlab by command in linux consule.
first you should find the PID number of matlab by this code:
top
then you can use this code to kill matlab:
kill
example:
kill 58056
To add on:
you can insert a time check within a loop with intensive or possible deadlock, ie.
:
section_toc_conditionalBreakOff;
:
where within this section
if (toc > timeRequiredToBreakOff) % time conditional break off
return;
% other options may be:
% 1. display intermediate values with pause;
% 2. exit; % in some cases, extreme : kill/ quit matlab
end