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