[lldb-dev] SBType/SBValue determine kind

Carlo Kok ck at remobjects.com
Thu Oct 18 04:16:08 PDT 2012


Op 17-10-2012 22:23, Carlo Kok schreef:
> 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).

I've got the same question for getting the current functions signature. 
(the real types, not the "c" version of them). I know they're in there 
somewhere.

Thanks,

--
Carlo Kok




More information about the lldb-dev mailing list