Inspecting local variables whose name collides with a built-in LLDB type

Subprojects LLDB
#1

Hi,

I use LLDB (lldb-310.2.37) to debug Firefox/Gecko. One of my biggest annoyances is that I can’t seem to make it inspect a local variable called ‘id’ (of which we have many) because ‘id’ is the name of a built-in LLDB type.

(lldb) p id

(lldb) p id.get()
error: cannot use dot operator on a type
error: 1 errors parsing expression

I can’t seem to find a bug on this - is there one on file? More importantly, is there some escaping mechanism I can use as a workaround?

Thanks,
bholley

#2

(lldb) frame variable id

should work

You won’t be able to say

(lldb) frame variable id.get()

but I am assuming get() will access some local ivar of “id”, which you might be able to do via frame variable

#3

We have a bug on our end for being able to compile expressions in any language flavor (C, ObjC, C++, ObjC++), but not in Bugzilla. Feel free to file one.

Currently we always run the expression parser using the ObjC++ language, though that's not strictly required. The expression parser uses some C++ features to capture the persistent variables ($var) defined in the course of the expression evaluation, so we can't back down to pure C without doing a fair bit of surgery. But it should be possible to do just C++. That would get you "id", though not much more.

Jim

#4

We have a bug on our end for being able to compile expressions in any language flavor (C, ObjC, C++, ObjC++), but not in Bugzilla. Feel free to file one.

That was unclear. Feel free to file one with the lldb bugzilla was what I meant to say...

Jim