Debugger output

[tigerbeard]

I noted that my GDB Watch gave me a incorrect value in the watch window.
The variable wxPoint ptDialgPos showed in the watch the values that gdb produced by the print command.
However, the output /c command produced other values.

Here is the section from the debugger command line while the debugee was running

Code Select Expand


> output /c ptDialogPos

[debug]> output /c ptDialogPos
[debug]{x = 96 '`', y = 8 '\b'}>>>>>>cb_gdb:

{x = 96 '`', y = 8 '\b'}
> print ptDialogPos

[debug]> print ptDialogPos
[debug]$2 = {x = 39395680, y = 8}
[debug]>>>>>>cb_gdb:

$2 = {x = 39395680, y = 8}


I guess the problem is in the printer scripts I am using, but I am acutally interested to understand why gdb outputs different values for the same variables at a given point. Why isptDialogPos.x=39395680 and isptDialogPos.x=96. If one is unicode, I would still not understand why y is the same...


using C::B V16.01, Win7, ollydbgs GDB from 2016-01-30

[oBFusCATed]

You're using "output /c" and "print", and the first treat integers as characters and the second uses the default treatment.
See here for details: https://sourceware.org/gdb/download/onlinedocs/gdb/Output-Formats.html#Output-Formats

note: Why are you talking about cdb in your first post? CDB is a debugger produced by microsoft and has nothing in common with gdb.

[tigerbeard]

note: Why are you talking about cdb in your first post? CDB is a debugger produced by microsoft and has nothing in common with gdb.

sorry, was a typo. Corrected it in the first post.

You're using "output /c" and "print", and the first treat integers as characters and the second uses the default treatment.
See here for details: https://sourceware.org/gdb/download/onlinedocs/gdb/Output-Formats.html#Output-Formats

Thanks for the link. I understood that without a format option like /c it prints a default, which might be a registered pretty-printer. I did not understand pretty printing so far, but thankfully the link also contains the native documentation of it with gdb. Seems like I need to get into that a bit deeper than intially anticipated :-)