[lldb-dev] SBType/SBValue determine kind

Carlo Kok ck at remobjects.com
Wed Oct 17 13:23:17 PDT 2012

Op 17-10-2012 21:51, Carlo Kok schreef:
> Op 16-10-2012 22:15, Greg Clayton schreef:
>> On Oct 16, 2012, at 11:58 AM, Carlo Kok <ck at remobjects.com> wrote:
>>> Op 16-10-2012 18:53, Greg Clayton schreef:
>>>> Yes, that was a funny typo bug that I didn't catch where I had:
>>>> switch (a) { case a1: switch b(b) case b1: base b2: }
>>>> Not the missing {} on the second switch! After switching to a
>>>> newer clang, we got the warning for unhandled switch statements
>>>> and I fixed it asap.
>> If it is a custom array type, you should look into writing a
>> synthetic formatter for it so it can act just like an array should.
>> We have many examples for std::vector, NSArray and more. Synthetic
>> formatters are little python plug-ins that can create child objects
>> for a given type, and also provide a summary string for the main type
>> (like "3 objects" for an array).
> cool. I take it it does this based on the type names? If I put say a
> type called Integer in the dwarf debug info it ends up an "int", "word"
> becomes unsigned short, etc, if I read it on the LLDB side. (though the
> DWARF debug info did have integer). Is there a way to get that original
> name back in LLDB? (I see there's a field in dwarf debug info even for
> pointers, if I can insert a name there I can distingiush between
> different types on the debugger side).

Maybe a way to access the dwarf debug info on Type/SBType?

I noticed that my 'Char' type, even though it's emitted as 
DW_ATE_unsigned_char size 16 ends up as an unsigned short.

(I use DW_ATE_signed/DW_ATE_unsigned for integer types and *char for 
actual character types to distingiush between the both).

More information about the lldb-dev mailing list