I am trying to augment sort of a printf or cout at certain breakpoints. Is there a way I can tell windbg to put a breakpoint and instead of breaking just list variables when execution flows through that breakpoint.
I tried to find about this on Google, but everywhere I get help related to breaking on certain condition.
I am sure there has to be a way of doing what I am trying to do.
Thanks for any help.
-Shobhit
A simple command would be
bp MyFunction "dv;g"
Where dv displays the local variables and then g continue execution.
Related
I want to print the addresses of all the local and global variables which are being used in a function, at different points of execution of a program and store them in a file.
I am trying to use gdb for this same.
The "info local" command prints the values of all local variables. I need something to print the addresses in a similar way. Is there any built in command for it?
Edit 1
I am working on a gcc plugin which generates a points-to graph at compile time.
I want to verify if the graph generated is correct, i.e. if the pointers do actually point to the variables, which the plugin tells they should be pointing to.
We want to validate this points-to information on large programs with over thousands of lines of code. We will be validating this information using a program and not manually. There are several local and global variables in each function, therefore adding printf statements after every line of code is not possible.
There is no built-in command to do this. There is an open feature request in gdb bugzilla to have a way to show the meaning of all the known slots in the current stack frame, but nobody has ever implemented this.
This can be done with a bit of gdb scripting. The simplest way is to use Python to iterate over the Blocks of the selected Frame. Then in each such Block, you can iterate over all the variables, and invoke info addr on the variable.
Note that printing the address with print &var will not always work. A variable does not always have an address -- but, if the variable exists, it will have a location, which is what info addr will show.
One simple way these ideas can differ is if the compiler decides to put the variable into a register. There are more complicated cases as well, though, for example the compiler can put the variable into different spots at different points in the function; or can split a local struct into its constituent parts and move them around.
By default info addr tries to print something vaguely human-readable. You can also ask it to just dump the DWARF location expressions if you need that level of detail.
programmatically ( in C/C++ ) you use the & operator to get the address of a variable (assuming it's not a pointer):
int a; //variable declaration
print("%d", a); //print the value of the variable (as an integer)
print("0x%x", &a); //print the address of the variable (as hex)
The same goes for (gdb), just use &
plus the question has already been answered here (and not only)
I'm currently in a Python interactive interpreter session. I have a function that I know is doing something funky, so I want to step through it in a debugger session. I know the file name and line number of the function.
Is there any way for me to now set a breakpoint in the start of that function, then run it and step through it? Without having to open an editor, locate the file, locate the function, manually insert import pdb; pdb.set_trace(), saving the file, then go back to the interpreter, reload the module the function came from and running it? Not to mention that if I forgot to remove the pdb trace that'd spell trouble later.
Summarizing the question: If I'm in a normal Python interpreter session (or iPython), is it possible to set a breakpoint somewhere and start debugging, without having to actually edit in the code pdb.set_trace() somewhere?
I can't believe I missed this, but I just glanced over the pdb documentation a second time and realized that all the run* functions do pretty much exactly what I want. They don't let me set a specific line as a breakpoint, but I can pass the function and the arguments I want to use, and it will break on the first line of the function:
import pdb
pdb.runcall(my_wonky_function, "arg1", "arg2", *myargs)
Well actually it broke at a mystical location called "EOF":
(Pdb) list
[EOF]
and I had to step twice before I got to the first line of the function, but that's hardly a problem.
You know how you can click the yellow arrow on a breakpoint and drag it down to skip execution of lines of code? Well, is it possible to create a "When Hit" macro (or something similar) that skips execution of the line containing the breakpoint?
So instead of writing code like
if(!Debugging)
Response.Redirect("LoginFail.aspx");
I could sit a breakpoint on the Response.Redirect() line and "When Hit" will skip it.
I don't know of baked in way of doing this. You can however set the "When hit" options of a breakpoint to run a macro. It shouldn't be hard to write a macro that gets the current line, and then sets the next debugger line. You'll probably want to look at the Debugger.SetNextStatement method.
A macro like this should do it:
Public Sub SkipNextLine()
ActiveDocument().Selection.LineDown()
DTE.ExecuteCommand("Debug.SetNextStatement")
End Sub
Yes, you can do this directly using a tracepoint.
Find the address of the return statement or final closing curly brace at the bottom of the function by breaking on it once, and then looking at the EIP register either in the Registers window or add a Watch for "#eip".
Add a tracepoint to the line you want to jump from. Remember that the jump will occur before anything on the line is executed. The content of the tracepoint should be {#eip = address} using the address from step 1.
See also https://stackoverflow.com/a/14695736/301729
There's no way I know of to do this with a breakpoint but you can use compiler directives to skip code
#if (DEBUG)
//this code is skipped in debug mode
#endif
Try:
#if DEBUG
Response.Redirect("LoginFail.aspx");
#endif
Make sure you have the DEBUG constant checked in your build properties.
Agree with the use of compiler directives or any other requiring to add logic in code. However, also understand editing the debugged code is not always an option (e.g. not owning the code might imply not having all resources needed to build it).
If that's your case, I'm afraid that writing your own macro or waiting for VS to have one built-in equivalent are your only options.
I'm trying to simplify my debugging tasks and I had an idea which could increase my debugging speed.
Suppose I have a value, say 2.8651 that appear in the code at a moment I do not know.
I'm wondering if it was possible to create a super breakpoint which would stop at the first time one of the variable takes this value.
I recall that I do not know which variable takes the value.
I could know it by spending some time on the debugger but I'm lazy.
I'm not really familiar with VBA for VS. I guess, a solution would be to create a macro which would loop along local variable at each line of the code execution. It'd stop when the condition localVariable == 2.8651 is verified.
Thank you for your answers!
There's no such thing as a super breakpoint for a block of code. There are two options to achieve what you want:
Place a conditional breakpoint on each line with a variable assignment. Right-click the breakpoint and click Condition... to specify when it should break.
Place a single conditional breakpoint in the code block and check all the required variables in the condition.
As you suggested, you can place a single breakpoint with a macro, by right-clicking the breakpoint and select When Hit.... However, I highly doubt that it's possible to control the breakpoint from the macro, so this wouldn't work.
I have some C++ code like this that I'm stepping through with GDB:
void foo(int num) { ... }
void main() {
Baz baz;
foo (baz.get());
}
When I'm in main(), I want to step into foo(), but I want to step over baz.get().
The GDB docs say that "the step command only enters a function if there is line number information for the function", so I'd be happy if I could remove the line number information for baz.get() from my executable. But ideally, I'd be able to tell GDB "never step into any function in the Baz class".
Does anyone know how to do this?
Starting with GDB 7.4, skip can be used.
Run info skip, or check out the manual for details: https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
Instead of choosing to "step", you can use the "until" command to usually behave in the way that you desire:
(gdb) until foo
I don't know of any way to permanently configure gdb to skip certain symbols (aside from eliding their debugging information).
Edit: actually, the GDB documentation states that you can't use until to jump to locations that aren't in the same frame. I don't think this is true, but in the event that it is, you can use advance for the same purpose:
(gdb) advance foo
Page 85 of the GDB manual defines what can be used as "location" arguments for commands that take them. Just putting "foo" will make it look for a function named foo, so as long as it can find it, you should be fine. Alternatively you're stuck typing things like the filename:linenum for foo, in which case you might just be better off setting a breakpoint on foo and using continue to advance to it.
(I think this might be better suited as a comment rather than an answer, but I don't have enough reputation to add a comment yet.)
So I've also been wanting to ignore STL, Boost, et al (collectively '3rd Party') files when debugging for a while. Yesterday I finally decided to look for a solution and it seems the nearest capability is the 'skip' command in GDB.
I found the 'skip' ability in GDB to be helpful, but it's still a nuisance for me because my program uses a lot of STL and other "3rd Party" template code. In this case I have to mark a bunch of files as skip. After the 2nd time doing so I realized it would be more helpful to be able to skip an entire directory--and most helpful to skip a directory and all subdirectories. That way I can skip, for example, /usr since none of my code lives there and I typically have no interest in debugging through 3rd party code. So I extended the 'skip' command in gdb to support a new type 'dir'. I can now do this in gdb:
skip dir /usr
and then I'm never stopped in any of my 3rd party headers.
Here's a webpage w/ this info + the patch if it helps anyone: info & patch to skip directories in GDB
It appears that this isn't possible in GDB. I've filed a bug.
Meanwhile, gdb has the skip function command. Just execute it when you are inside the uninteresting function and it will not bother you again.
skip file is also very useful to get rid of the STL internals.
As Justin has said, it has been added in gdb 7.4. For more details, take a look at the documentation.