How to ignore class methods in the same line while debugging with Eclipse? - c++

Configuration:
Eclipse Luna, debugging a C++ code with gcc.
Question:
Consider the code below, where I set the break point:
myFunction( someString.c_str() ); // << Break point is here
I want step-into directly to the myFunction, ignore the 'c_str()' call
Note: I am trying to avoid the obvious solution, which is to put a break point inside the the myFunction call.

This is what to do when the debugger hits the main line:
Hit 'F5: Step Into'
The debugger step into the 'c_str()' method. (You may not want that).
Hit 'F7 - Step Return'
The debugger will exit 'c_str()' and return to the entry point of the 'myFunction' call.
Hit 'F5 Step Into'
Now the debugger will go into the 'myFunction' call

Related

VS Code "step into" debugger configuration

When I debug my C++ project in VS Code and toggle a breakpoint, The "step into" option redirecting me to external files/libraries, but I want to step only into my code.
I tried to add "justMyCode": true option in launch.js file, but it says this property is not allowed.
What can I do to go only through source code?
One thing could be done for this issue. I actually tested my own test program:
std::vector<std::string> name;
std::cout << "Enter a name: ";
std::getline(std::cin, name);
nameList.push_back(name); // BREAKPOINT
When we select Step Into in the breakpoint execution, it redirects into the definition of the function where it's actually defined, it's not going to debug only for your file in this case.
Step Into Type:
Rather, you must use Step Over since it doesn't tries to find the function definitions and you would able to debug your content straightforwardly.
Step Over Type:
The Step Into will certainly redirect you into the function definition wherever it's defined, if you want to know the declaration and other things about the related function, it's good opportunity to use Step Into. But in case you just want to debug the line only and not considering to go in depth and don't want to get jumped into another file, you must use Step Over.
If you want to know more about Step Into and Step Over, you can go through this Stack Overflow thread. I've found this helpful too.
This is not a perfect answer,
Suppose you are debugging code this:
func_that_we_care ( func_that_we_dont_care( i) ); <== step into this line
and you fall into 'func_that_we_dont_care', you can 'step out' there, then 'step into' again, eventually you will be able to step into 'func_that_we_care'.

lldb: conditional breakpoint on a most derived type

typical debugging pattern:
class Button : public MyBaseViewClass
{
...
};
....
void MyBaseViewClass::Resized()
{
//<---- here I want to stop in case MyBaseViewClass is really a Button, but not a ScrollBar, Checkbox or something else. I.e. I want a breakpoint condition on a dynamic (most derived) type
}
trivial approaches like a breakpoint on strstr(typeid(*this).name(), "Button") don't work because on typeid lldb console tells:
(lldb) p typeid(*this)
error: you need to include <typeinfo> before using the 'typeid' operator
error: 1 errors parsing expression
surely #include in console before making the call doesn't help
You can do this in Python pretty easily. Set the breakpoint - say it is breakpoint 1 - then do:
(lldb) break command add -s python 1
Enter your Python command(s). Type 'DONE' to end.
def function (frame, bp_loc, internal_dict):
"""frame: the lldb.SBFrame for the location at which you stopped
bp_loc: an lldb.SBBreakpointLocation for the breakpoint location information
internal_dict: an LLDB support object not to be used"""
this_value = frame.FindVariable("this", lldb.eDynamicDontRunTarget)
this_type = this_value.GetType().GetPointeeType().GetName()
if this_type == "YourClassNameHere":
return True
return False
DONE
The only tricky bit here is that when calling FindVariable I passed lldb.eDynamicDontRunTarget which told lldb to fetch the "dynamic" type of the variable, as opposed to the static type. As an aside, I could have also used lldb.eDynamicRunTarget but I happen to know lldb doesn't have to run the target go get C++ dynamic types.
This way of solving the problem is nice in that you don't have to have used RTTI for it to work (though then we'll only be able to get the type of classes that have some virtual method - since we use the vtable to do this magic.) It will also be faster than a method that requires running code in the debugee as your expression would have to do.
BTW, if you like this trick, you can also put the breakpoint code into a python function in some python file (just copy the def above), then use:
(lldb) command script import my_functions.py
(lldb) breakpoint command add -F my_functions.function
so you don't have to keep retyping it.

How to change a variable value on conditional breakpoint in visual studio 2015

Is there any way to change value of variable to on a conditional breakpoint and continue execution.
My code is like this
switch(var){ //conditional breakpoint on this line
case 1:
break;
...
}
I put conditional breakpoint like below
(var == 0 ) || (var ==1) is true
So when this breakpoint hits, I want to change var = 2, and continue execution.
What I found: I found Action also, but it only log messages. Is there any way to executing a statement like var = 2 as Action taken on this conditional breakpoint.
I don't want to change code because building it takes hell lot of time.
Note: I am working C++ on Visual studio 2015
In Log a message to Output Window write {my_variable=12345} the side effect of log output is assigning 12345 to my_variable.
Take into account that Log a message can accept and evaluate complex expressions in curly braces.
You can modify a variable directly in memory to change the execution flow through a quick watch (Shift+F9) or watch window in Visual Studio.
Make sure that in Tools / Options / Debugging you have the "Enable Edit and Continue" Enabled/Checked and then you will be able to edit your code while debugging and continue without the need to rebuild or to stop execution.
More information can be found in How to: Enable and Disable Edit and Continue
This used to work, I can't seem to get it to work now. Worked excellent on loops and also good for altering values without altering the source or the code (and accidently committing it).
Conditional break point, break if true
(url = "http://localhost:1234/") != url
This works thanks to assignment always returns it's assigned value. This will never be true as url becomes localhost

llvm irbuilder call instruction throwing exception on function inlining pass

I'm new to LLVM. I am using the clang c++ API to compile multiple stub files (in c) to IR, and then stick them together using IR builder (after linking them) to eventually run via JIT.
All this works great, unless I add a functionInlining pass to my optimizations, at which point one of these function calls made in IR builder will trigger the following exception when the pass manager is run:
Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/mike/Development/llvm/llvm/lib/IR/Value.cpp, line 356.
This is how I make the call instruction (pretty straight forward):
Function *kernelFunc = mModule->getFunction( (kernel->Name() + StringRef("_") + StringRef(funcName)).str());
if (kernelFunc){
CallInst* newInst = builder.CreateCall(kernelFunc, args);
}
Later the module is optimized:
legacy::PassManager passMan;
PassManagerBuilder Builder;
Builder.OptLevel = 3;
//Builder.Inliner = llvm::createFunctionInliningPass(); //commenting this back in trigger the exception
Builder.populateModulePassManager(passMan);
passMan.run( *mModule ); //exception occurs before this call returns
Any ideas what to look for?
Try running llvm::verifyModule on your module to see if it's correct. You might have an error and have been getting lucky beforehand but it tripped something up in the inliner.
In general assertions check a subset of things that can be wrong with your module but verify checks a lot more.
It could be a bug in LLVM but more than likely it's a bad module, it's easy to happen.
So I finally setup my dev environment so I could inspect the assertion call in the debugger. I turns out the basic block being replaced had a different context set than the one it was being replaced with. going back and making sure IRBuilder was using the same context as the IR parsers solved the problem.

Visual Studio Breakpoint Macro to modify a value?

I'm debugging an application (C++), and I've found a point in the code where I want to change a value (via the debugger). So right now, I've got a breakpoint set, whereupon I do:
Debugger reaches breakpoint
I modify the variable I want to change
I hit F5 to continue running
lather, rinse, repeat
It's hitting this breakpoint a lot, so I would like to automate this. I would like to set the Breakpoint to run a macro, and continue execution.
However, I have no experience writing VisualStudio macros, so I don't know the commands for modifying a variable of the executing program. I've looked around, but haven't found anything helpful online so far.
I found how to do this with a macro. Initially, I tried using Ctrl-Shift-R to record a macro of keystrokes, but it stopped recording when I did Ctrl-Alt-Q. But I was able to edit the macro to get it to work. So here's what I did, in case anyone else wants to do something similar.
Tools -> Macros -> Macro Explorer
Right Click -> New macro
Public Module RecordingModule
Sub setvalue()
DTE.Debugger.ExecuteStatement("variable_name=0")
End Sub
End Module
This macro will execute the assignment statement, setting my variable (in this case, making it a NULL pointer).
Right Click on a BreakPoint -> When Hit...
Check "Run a macro"
Select Macros.MyMacros.RecordingModule.setvalue
Check "Continue execution"
Click OK
Then, I was able to run my program, automatically adjusting a pointer to NULL as it went. This was very useful for testing, and did not require recompiling.
Looking for similar today and found that you can also use the 'Print a message:' option instead of a macro. Values from code can be printed by placing them inside {}. The key is that VS will also evaluate the content as an expression - so {variable_name=0} should achieve the same as the macro example.
If you are think of a macro in the same way as Microsoft excel, then you're out of luck. It doesn't quite work that way.
In C++, a macro refers to a small inline function created with #define. It is a preprocessor, so a macro is like using a replace on all its references with its body.
For example:
#define add(a,b) ((a)+(b))
int main() {
int a=3, b=4, c=5, d=6, e, f;
d = add(a,b);
e = add(c,d);
}
Would like to the c++ compiler as:
int main() {
int a=3, b=4, c=5, ...;
d = ((a)+(b));
e = ((c)+(d));
}
Now, back to your question. If the variable is within scope at this breakpoint, just set it from within your code:
myVar = myValue;
If it is not, but it is guaranteed to exist, you may need a little hack. Say that this variable is an int, make a global int pointer. If this variable is static, make sure to set it to its address, and back to NULL inside it's scope. If it is dynamic, you may need some extra work. Here is an example:
int* globalIntPointer;
void func() {
*globalIntPointer = 3;
//...
}
int main() {
int a = 5;
globalIntPointer = &a;
func();
//...
globalIntPointer = NULL; // for safety sake
return 0;
}
You can execute a VS macro when a breakpoint is hit (open the breakpoints window, right click on the breakpoint in question, and select "When Hit..." off the popup menu). I'm less certain about writing a macro that modifies a variable of the program under debug though -- I've never done that, and a quick try with attempting to record a macro to do it doesn't seem to work (all it records is activating the right window, not changing the value).
Select "Condition..." and write an assignment for the variable in question in the "Condition:" textbox. This will naturally resolve to "true" with it not being an actual conditional test. Therefore, the breakpoint is never hit, and your variable has been set accordingly.