I want to be able to see the variable values while debugging a release application.
I have set the compiler option as Z7 and given a /DEBUG and /PDB: linker option. Now I have a pdb for the application.
With this set up I am able to put a break point (Windbg) inside the code and it hits properly. But I am not able to see the variable values.
The Locals window only shows the pointer value but I cant see the contents of the same. For instance if I have a pointer to a structure that has an int inside it, it just shows the value of the pointer. If I expand the same by clicking + in the tree, I see the variable name with the value as <Memory access error>
How should I make the release builds show the variable values?
Many times, you cannot see them because they don't exist. If you look at the optimized assembly code, you will find that many intermediate variables are completely removed in favor of performance. That is most likely what you're seeing, and the only way around it is to follow the disassembly and watch the right memory locations / registers.
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)
gdb provides a command "print localx" which prints the value stored in the localx variable. So, it basically must be using the symbol table to find the mapping (localx -> addressx on stack). I am unable to understand how this mapping can be created.
What I tried
I studied the intermediate temporary files of gcc using -save-temps option, and observed that a local variable local1 was mapped to a symbol name "LASF8". However, the objdump utility tool did not show this symbol name.
Context :
I am working on a project which requires building a pin-tool to print the accesses of local variables. Given a function, I would like to say that this address corresponds to this variable name. This requires reading the symbol table to correspond an address to a symbol table entry. GDB does the exact reverse mapping. Hence, I would like to understand the same.
The symbol table is contained in the debugging information. This debugging information is emitted by gcc -g. gdb reads the debugging information to get symbolic information, among other things.
Typically the debugging information is in DWARF format. See http://www.dwarfstd.org/ for the specification.
You can also see DWARF more directly using readelf. For example readelf -wi will show the main (".debug_info") debugging information for an ELF file.
Note that doing the mapping in reverse -- that is, assigning a name to every stack slot -- is not entirely easy. First, not every stack slot will have a name. This is because the compiler may spill temporaries to the stack. Second, many locals will have DWARF location expressions to represent their location. This means you'll need to write an expression evaluator (not hard but also not trivial); you could conceivably (unlikely in practice but possible in theory) run into expressions which cannot be evaluated without a real stack frame; and finally the names will therefore generally only be valid at a given PC.
I believe there's a feature request in gdb bugzilla to add this feature to gdb.
I'm using XCode to debug some code. Specifically, the code that I'm debugging exposes a float[][] as float**. I am unable to change this syntax, but I'm not certain it would help anyway.
After including a relevant breakpoint, I want to view the contents of the array in the Variables view of the debugger?
When I double-click on the variable in the list of Autos, I see that I can add a Summary Format which seems deceivingly like it might help, but for the life of me, I can't figure out how to use it!
In conclusion, how do I use the Variables View to see the contents of my array of arrays of this primitive type without resorting to typing commands directly to GDB (which, I believe, can also perform this function)?
I'm using XCode 4.2. When I set a breakpoint and check the values of my variables (whether they be Auto, local, or expressions I enter myself) the values return with "empty" type values (integers = 0, BOOL=false, etc. The structure of my objects are correct, but the values don't display the correct information.
Watching the program execution flow confirms that the variables have a value other than the "empty" one since loops and conditional work correctly based on what the variables SHOULD contain.
I am assuming that my debug symbols are not being created correctly (or are corrupt), but I am not sure how to set that in XCode.
I have tried:
I have confirmed that my schema is debug.
I have changed my debugger to GDB
Can anyone help me out?
I've run into an exception and looking at variables in the watch window, I'm seeing some question marks (???). Does this mean it's pointing to an invalid address?
It means that the debugger can't figure out its value.
For example, you see this quite a bit if your code involves HWNDs. If you look through the Windows header files, it's defined like this via a macro:
struct HWND__{int unused;}; typedef struct HWND__ *HWND;
So the type of HWND is really the type "pointer to an HWND__". However, the HWND values you get from functions like CreateWindow() aren't actually pointers to anything.
But the debugger will try to figure out the value of the unused member in the struct, but can't do it:
You will also see these kinds of errors when the watched variable has bad or missing type information.
Is this a C++ style project?
The debugger typically uses the "???" string when it is able to evaluate an expression but is unable to garner any type information for a specific part of the display. This typically occurs because of missing or incorrect PDB symbols.
There is likely a way for this to occur if the expression is accessing corrupted data (overriten virtual tables or RTTI). But I do not 100% know if that is true.
Usually it means the pointer or reference is pointing to inaccessible memory, and thus it cannot get the value to present. For example, if you have a pointer that's supposed to point to a Foo, the debugger will normally interpret the bits that the pointer points to as a Foo--whether the pointer is valid or not. But in some cases, a wild pointer might point to a location that's not even mapped in the process space. In that case, the debugger cannot get the bits.