SBType/SBValue determine kind

Given an SBValue (or it's type SBType) how do I find out what kind of type it is? (Like int32, int16, int8)

You can call:

SBType
SBValue::GetType();

SBType will describe the type itself. We recently added an enumeration call:

lldb::BasicType
SBType::GetBasicType();

This will return an enumeration that describes your type if is is a basic type (see the lldb::BasicType enumeration definition for details).

Op 15-10-2012 18:52, Greg Clayton schreef:

You can call:

SBType
SBValue::GetType();

SBType will describe the type itself. We recently added an enumeration call:

lldb::BasicType
SBType::GetBasicType();

This will return an enumeration that describes your type if is is a basic type (see the lldb::BasicType enumeration definition for details).

Cool. So I tried that and I get back a eBasicTypeBool for both types in the attached IR file. I emit it with DIBuilder and pass an DW_ATE_signed 32bits:

!9 = metadata !{i32 786468, null, metadata !"Integer", null, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [Integer] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]

Is there something special I have to do here? (Integer is the internal name for this type in my language)

out.txt (4.37 KB)

Op 16-10-2012 15:33, Carlo Kok schreef:

Op 15-10-2012 18:52, Greg Clayton schreef:

You can call:

SBType
SBValue::GetType();

SBType will describe the type itself. We recently added an enumeration
call:

lldb::BasicType
SBType::GetBasicType();

This will return an enumeration that describes your type if is is a
basic type (see the lldb::BasicType enumeration definition for details).

Cool. So I tried that and I get back a eBasicTypeBool for both types in
the attached IR file. I emit it with DIBuilder and pass an DW_ATE_signed
32bits:

!9 = metadata !{i32 786468, null, metadata !"Integer", null, i32 0, i64
32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [Integer] [line
0, size 32, align 32, offset 0, enc DW_ATE_signed]

Is there something special I have to do here? (Integer is the internal
name for this type in my language)

Nevermind. This got fixed 1 lldb revision after I did my last up merge of the Windows branch.

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.

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).

Greg Clayton

Op 16-10-2012 22:15, Greg Clayton schreef:

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

Op 17-10-2012 21:51, Carlo Kok schreef:

Op 16-10-2012 22:15, Greg Clayton schreef:

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).

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:

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,