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 <[email protected]> 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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
