Suppose I define a new gdb command which includes an alias.
import gdb
import string
class PrettyPrintString (gdb.Command):
"Command to print strings with a mix of ascii and hex."
def __init__(self):
super (PrettyPrintString, self).__init__("ascii-print",
gdb.COMMAND_DATA,
gdb.COMPLETE_EXPRESSION, True)
gdb.execute("alias -a pp = ascii-print", True)
Now, I'd like to make a small change to the script and source it again in the same gdb session. Unfortunately, when I try to source again, I get the following error.
gdb.error: Alias already exists: pp
How can I delete the original alias and source the updated script?
Note that the alias documentation does not appear to say anything about deleting aliases, and I tried unalias and delete but neither had the desired effect.
You can define a keyword to a function instead of as an alias. For example I have
define w
where
end
in my .gdbinit. And re-defining works, as opposed to re-aliasing.
I am trying to follow pointers to templates on LLDB. I keep failing, as in (names changed to protect the guilty):
> (lldb) expr *(p->q->r)
(x::y) $5 = {
x::z<t::u> = {
...
> (lldb) expr p->q->r->x::z<t::u>
error: 'x::z' is not a member of class 'x::y'
(lldb)
There's got to be a way to do it, since the Clion IDE (using LLDB as its debugger) lets me click on such links as deeply as they go, template or no template. So how is this done in bare LLDB?
(yes, I looked high&low for documentation)
Does anyone know why, in certain places, Python code inside of gdb doesn't properly handle exceptions? Or, to clarify, perhaps the exception message
is going somewhere other than the *gud buffer. gdb is not returning control
to the prompt, as expected.
(I'm using GNU gdb (GDB) 7.11.50.20160212-git in Emacs (24.5.1) gud mode)
For example:
class SomeEvent():
def __init__(self, ...):
... do something ...
def __call__(self):
... do something BAD here ...
gdb.post_event(SomeEvent())
When 'SomeEvent' is handled, it will just execute '__call__' up to the bad code, return, and then continue normal operation (as I can observe).
I've noticed this behavior in other 'callback' type methods, such as Stop() of a subclassed gdb.Breakpoint.
gdb.post_event ignores exceptions when the event object is invoked. You can see this clearly in the source code, in gdbpy_run_events:
/* Ignore errors. */
call_result = PyObject_CallObject (item->event, NULL);
if (call_result == NULL)
PyErr_Clear ();
This seems like a bug to me -- it would be more useful to print a stack trace or something instead.
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.
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.