I searched but can't find a good solution. Is that possible,why?
LLDB doesn't support breakpoint commands that can run the debugee a bit and then perform further steps. The breakpoint commands terminate when the debugee starts up again. So you can't use breakpoint commands to do this. This is a restriction that will be fixed at some point but it is not a trivial piece of work.
However, lldb also has a "scripted step" feature that allows you to craft your own custom step operations. You could use that to work around this restriction. The FinishPrintAndContinue in the examples file:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/scripted_step.py
is almost what you want. You just need to change the continue to check the return value (using SBThread::GetStopReturnValue) and then continuing or stopping depending on the result. Then you could put a breakpoint on the function in question and adds a command that runs this fancy step.
Related
I have a code base of almost 16000 lines of C code in which I am performing different operations (on a Raspberry Pi). After each operation, I am updating the value of dc. dc is initially 0 and if through some error my controller loses its connection with my laptop it becomes 1.
I need to call a function whenever it goes 1. I heard of a function in JavaScript called Object.prototype.watch() and unwatch(). Basically what it does is watches a variable and whenever its value changes, it calls a function. I need to implement a similar function or statement or anything that calls a function when my dc value changes.
I cannot use if-else after each update of dc because it is not a good way of coding and there are going to be a lot of if-else if I use it.
Nothing like this exists. Interpreted or managed languages have completely different rules. There is no other way than if.
You can wrap it into some kind of assertion or function but there is no other way than if in that wrapper
The sad answer is: No, there's no reliable way to watch a variable in C this way.
Depending on how the code works there are some workarounds.
One way is to hide (yes I know, it's hard to hide stuff completely in C) the variable. Define functions:
int noConnection() { return _noConnection; }
void lostConnection() { _noConnection = 1; myFunction(); }
Another way is to code some monitor that checks the variable at regular intervals. A drawback is if you really need this function to be run every time it changes, because it will not catch the event that a variable is changed and changed back between checks.
If the variable is not referenced by any pointers then you already know the places where it is updated, so you can use visibleman's method. There won't be a lot of if-elses like you anticipated. Just create a function like this
inline void update_dc(int new_dc) // or a macro if you want,
{ // but inline functions are more preferrable
#ifdef DEBUG_DC
if (new_dc == 1) // or if (new_dc != dc)
{
trap();
}
#endif
dc = new_dc;
}
and replace all assignments to dc with this function. You can do that easily with a regex in any text editors' find/replace command, or find/sed in the terminal
However in the general case when you don't know exactly at what point it can be updated, the easiest way is using a separate thread for watching it. You'll do some kind of polling by using a timer, or by checking the value and then sleep for some time to avoid wasting CPU usage. But you won't get the exact place where the change happens, unless you insert a value check after every instruction, which slows down your app many times.
You may also run a debugger like gdb and attach it to your own process to watch. It'll be a lot more flexible this way, but you'll need more memory. You can also try some debugging library if available
See Is is possible to set a gdb watchpoint programatically?
Many architectures do have hardware watch points, so debuggers will try to use them up before turning up to software watching (which is extremely slow). If you know about the architecture you can also set up the debug registers manually like that instead of running a full-fledged debugger. Of course most of the time you'll need to run in privileged mode to set those registers
On x86 there are 3 breakpoints stored in DR0-DR3 which will break on execution, data write, data read/write and IO read/write. I don't know the situation on ARM but it seems to have 6 hardware breakpoints. You can check those on ARM's documentation if you want to go that way.
The most straightforward solution seems to be to stop changing the variable directly and write a getter and setter function, that will call some callback.
I want gdb to dump the code it executes line by line. Just like step command as it shows the current line but I do not want do step through the entire code as it is too big.
So I want to automate it.
The reason I want to do this because my code behaves differently in two scenarios and I want to see where actually the diff arises so I plan to take dump for two different scenarios in two different file then take a diff.
I know it may not be the best way to debug something but trust me I have tried a lots of stuff to find the bug but no use and I think this can help me in a great way.
Thanks in advance !!
With GDB you can set breakpoints that will allow you to follow step by step the code in a specific area of your programm.
I have just discovered C-x C-a C-j (jump to cursor) when running gdb in emacs. I initially assumed that it was the equivalent of setting a break wherever the cursor is and continuing (c) to that statement. However I seem to be observing the behaviour that when using jump none of the intervening statements (between the prev breakpoint and the current cursor location) are being executed. Can anyone confirm or deny this?
I guess if it isn't executing the statements it is equivalent to being able to comment out a block of code 'from within' the debugger, i.e. without having to go back into the src, explicitly comment out and then recompile. I can see that could be useful, but it definitely wasn't what I was expecting.
If that is what's happening then a follow up question would be is there a 'continue to cursor' command (where the intervening statements do get executed)?
I believe what you need is C-x C-a C-u (M-x gud-until) instead of M-x gud-jump. The latter, as the Emacs manual quite clearly states, simply
transfers the program's execution point to the current line. In other words, the next line that the program executes will be the one where you gave the command [...] See the GDB manual entry regarding jump for details.
I am writing a relatively simple C program in Visual C++, and have two global variables which I would like to know the values of as the program runs. The values don't change once they are assigned, but my programming ability is not enough to be able to quickly construct a text box that displays the values (I'm working in Win32) so am looking for a quick routine that can perhaps export the values to a text file so I can look at them and check they are what they ought to be. Values are 'double'.
I was under the impression that this was the purpose of the debugger, but for me the debugger doesn't run as the 'file not found' is always the case.
Any ideas how I can easily check the value of a global variable (double) in a Win32 app?
Get the debugger working. You should maybe post another question with information about why it won't work - with as much info as possible.
Once you have done that, set a breakpoint, and under Visual C++ (I just tried with 2010), hover over the variable name.
You could also use the watch window to enter expressions and track their values.
If your debugger isn't working try using printf statements wherever the program iterates.
Sometimes this can be a useful way of watching a variable without having to step into it.
If however you wish to run through the program in debug mode set a breakpoint as suggested (in VS2010 you can right click on the line you want to set a breakpoint on).
Then you just need to go to Toolbars -> Debug Toolbar.
I usually like to put #ifdef _DEBUG (or write an appropriate macro or even extra code) to do the printing, and send to the output everything that can help me tracking what the program's doing. Since your variables are never changing, I would do so.
However, flooding the console with lots of values is bad imo, and in such cases I would rely on assertions and the debugger - you should really see why it's not working.
I've done enough Python and Ruby to tell you that debugging a complex program when all you have is a printf, although doable, is extremely frustrating and takes way longer than what it should.
Finally, since you mention your data type is double (please make sure you have a good reason for not using floats instead), in case you add some assertion, remember that == is to be avoided unless you know 100% that == is what you really really want (which is unlikely if your data comes from calculations).
This may sound like a silly question but I could see no mention anywhere of this particular problem. Basically:
I want to execute a Lua script line by line, primarily to have the ability to pause/resume execution anytime and anywhere I want. What I do is simple: load a chunk with luaL_loadbuffer() and then issue a lua_pcall().
Thing is... How can I properly detect Lua blocks in order to execute them atomically?
For instance, suppose there's a function in the script -- by executing the file line by line with the method described above, I can't seem to have a way to properly recognize the function, and in consequence its contents are loaded and called one by one.
I can imagine that one solution would be to manually handle a stack where I push control keywords I can recognize in the script ("function", "if", "do", etc) and their corresponding "end" clause if I find nested blocks. Once I push the final "end" I call the entire block, but that sounds simply awful. Surely there must be a better way of doing this.
Hope it makes some sense, and thank you!
Please take a look at Lua coroutines to implement that functionality for scripting game entities. The idea is to yield the coroutine in the sleep() and waitforevent() routines you mentioned, and then resume later (e.g. after a timeout or event occurs).
Use lua_sethook().
Note that you probably do want to experiment with what exact hook call granularity you need. I'd recommend executing chunks of bytecode instructions instead. One really long line may contain many instructions.