How to print and use constants with gdb (through Xcode)? - cocoa

Question

I am debugging a Cocoa application using xcode-gdb. I am at a break point and I want view the value of some Cocoa constants (ie NSControlKeyMask) and to do some test with the values in the current stackframe. Specifically I am in - (void) keyDown:(NSEvent *) e , and I have done set $mf = (int)[e modifierFlags] on the gdb prompt. Now I want to do p $mf & NSControlKeyMask and gdb is telling me 'No symbol "NSControlKeyMask" in current context.'
UPDATE:
Xcode has the "Fix and Continue text" feature. So I used Dan M. and n8gray solution with this feature so I don't have to make a proxy of every constant.

Answer 1

If no variables are actually instantiated with a given type, then the debug information for the corresponding symbols doesn't wind up getting generated by gcc. Then, if you ask gdb about such a type, it doesn't know what you are talking about because there is no debug information for that type, and it will give you the "No symbol in current context" error.
A workaround to this problem would normally be to explicitly add a dummy variable, of the type in question, somewhere in the code. Here is a simple example that you can test to see what I'm talking about:
enum an_enum_type {
foo,
bar,
baz
};
int main (int argc, char *argv [])
{
return baz;
}
Save that program to a file named test.cpp and compile it with this command:
g++ -o test -g -O0 test.cpp
Then run it under gdb and type "p /x baz". You will get the "No symbol baz in current context" error.
Now try it with this modified version that has added a dummy variable, of the enum type:
enum an_enum_type {
foo,
bar,
baz
};
an_enum_type dummy;
int main (int argc, char *argv [])
{
return baz;
}
Compile with the same command as before and run under gdb. This time when you type "p /x baz" you'll get "0x2" as the answer, which I think is what you are shooting for in your question.
I've looked into it, and the problem is that the NSEvent.h header file doesn't give a name to the enum that contains NSControlKeyMask -- it's an anonymous enum. So there is no way to create a variable of that type (dummy or otherwise). So, I don't see any way of getting the compiler to generate the debug information for that type. I think you're just going to have to rely on the definition of NSControlKeyMask from the header file.

Answer 2

If you compile with gcc you can use the -g3 switch to get the highest level of debug info. Quoting from the section on -g in the gcc manual:
-glevel
Request debugging information and also use level to specify how much information. The default level is 2.
Level 0 produces no debug information at all. Thus, -g0 negates -g.
Level 1 produces minimal information, enough for making backtraces in parts
of the program that you don't plan to debug. This includes descriptions
of functions and external variables, but no information about local
variables and no line numbers.
Level 3 includes extra information, such as all the macro definitions present
in the program. Some debuggers support macro expansion when you use
-g3.
So if you compile with -g3 you should be able to expand constants and macros in gdb.

Answer 3

As Dan M. discovered, you probably can't get this to work in a straightforward way. Instead, what you could do is put something like this in one of your files:
int myNSControlKeyMask = NSControlKeyMask;
int myNSOptionKeyMask = NSOptionKeyMask;
...
Then at least you can use symbolic names in gdb without having to look up the corresponding values in the .h file.

Answer 4

NSControlKeyMask is most likely a macro and invisible to the debugger. You need to look in the appropriate .h file. Place the cursor over the text NSControlKeyMask in the editor and try command+double-click to jump to its definition.

Answer 5

I seem to be getting the same problem in a bunch of C++ code that is being called from Obj-C in an iPhone app. It's giving me the
No symbol "a" in current context.
error, where a is an int. I tried the -g3 compiler flag with no success. I find it hard to believe gdb doesn't know the type of an int. SDK 3.0, but then again, gdb was printing completely erroneous values when it could find variable in the program.