[lldb-dev] SBType/SBValue determine kind

Carlo Kok ck at remobjects.com
Wed Oct 17 12:51:31 PDT 2012


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.
>>>
>>
>> nice one yeah. So after playing with debugging for a while I
>> noticed it's very "clang" oriented. While I don't really mind that,
>> is there a way to store more custom language specific information?
>> (I have control over both generation & lldb api) For example I have
>> an array type that from the LLDB api looks like a pointer to it's
>> sub type. There's a "length" field before it, and from the LLDB
>> side I Want to look at the "length" and use it to display the sub
>> entries, but then I have to store & know it from both side.
>
> 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).

Thanks,

Carlo Kok



More information about the lldb-dev mailing list